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Foreword 



This Technical Specification (TS) has been produced by ETSI Project Broadband Radio Access Networks (BRAN). 

The present document describes the functional requirements for Radio Link Control sublayer of High PErformance 
Radio Local Area Network Type 2 (HIPERLAN/2) systems. Separate ETSI documents provide details on the system 
overview, physical layer, data link control layer, convergence sub-layers and conformance testing requirements for 
HIPERLAN/2. 

The present document is part 2 of a multi-part TS covering the HIPERLAN Type 2; Data Link Control (DLC) Layer, as 
identified below: 

Part 1: "Basic Data Transport Functions"; 

Part 2: "Radio Link Control sublayer". 
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Scope 



The present document specifies the basic Radio Link Control (RLC) sublayer of HIPERLAN/2. The RLC sublayer is 
used to control radio association, resources and connection.HIPERLAN type 2 is confined to the two lowest layers of 
the open systems interconnection (OSI) model, the physical and the data link control layer. The TR 101 683 [21] 
contains an overall description of the HIPERLAN type 2 system. 

The interworking with higher layers is handled by convergence layers on top of the data link control layer. The Packet 
based Convergence Layer is described in [18], [19], [20] and the Cell based Convergence Layer in [16], [17]. 

The PHY layer is described in [4]. 

The present document does not address the requirements and technical characteristics for type approval and 
conformance testing. These are covered by separate documents. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Access Point: device that is responsible for the centralized control of the resources in a radio cell. It is usually 
connected to a fixed network 

Association: process where an MT gets a MAC-ID from an AP. A Dedicated Control CHannel (DCCH) is established. 
Basic link layer parameters are agreed on between an MT and an AP. Encryption start up and authentication are done, if 
the use of them is decided on for this association. Information between convergence layers in the MT and the AP may be 
transferred 

Association Control Function: group of control functions that use the services of the RLC. These functions are 
responsible for the handling of the association between MT and AP 

Association control CHannel: logical channel in the uplink that conveys new association request messages 

Authentication: corroboration that a peer entity in an association is the one claimed 
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Broadcast CHannel: transport channel that broadcasts control information 

Broadcast Control CHannel: logical channel that broadcasts control information which is relevant for the current 
MAC frame 

Broadcast frame: MAC frame sent at regular intervals, wherein all MTs in a cell are listening, sleeping ones included 

Broadcast phase: part of a MAC Frame in which the AP sends pure control signalling which can be received by any 
MT in the range of the AP. The Broadcast phase consists of Broadcast Control Channel, Frame Control Channel and 
Access Feedback CHannel 

Central Controller: provides control functionality equivalent to that of an access point but is not necessarily attached 
to a fixed network. This term is normally used if central controller and MT functionality are located in a single device. It 
mostly involves direct mode communication 

Centralized Mode: in centralized mode, all data transmitted or received by a mobile terminal shall pass the access point 
or the centralized controller, even if the data exchange is between mobile terminals associated to the same access point 
or centralized controller 

DLC connection: HIPERLAN/2 DLC operates connection oriented. A DLC connection carries user or control data and 
is identified by a DLC connection identifier. A connection has a set of properties for the transfer of data agreed upon 
between the MT and the AP or between MTs and a CC 

DLC User Connection: DLC user connection is uniquely identified by the DLC connection ID and a MAC-ID 

DLC User Connection Control: group of control functions that uses the services of the RLC. It is responsible for the 
handling of DLC user connections 

Direct Mode: data exchange between MTs associated with the same AP or CC takes place without passing but under 
control of the access point or the central controller 

Direct link phase: part of a MAC frame that only contains the data exchanged directly between MTs using direct mode 
communication methods 

Downlink phase: part of the Downlink transmission of a MAC Frame during which user and control data is transmitted 
from the access point or central controller to mobile terminals. The data transmitted can be user as well as control data 
in unicast, broadcast and multicast modes 

Encryption Function: function that is responsible for keeping user data and part of RLC signalling secret between 
HIPERLAN/2 devices 

Error control: error control is responsible for detection of transmission errors and, where appropriate, for the 
correction of errors 

Forward-Handover: handover where MT may not inform the old AP/APT about its intention to change to another 
AP/APT 

Frame CHannel: transport channel that is broadcast and which carries the frame control channel 

Frame Control CHannel: logical channel that contains the information defining how the resources are allocated in the 
current MAC frame. Its content changes in general dynamically from frame to frame 

Logical channel: generic term for any distinct data path. A set of logical channel types is defined for different kinds of 
data transfer services. Each logical channel type is defined by the type of information it carries. Logical channels can be 
considered to operate between logical connection end points 

MAC Frame: periodical structure in time that appears on the air interface and that determines the communication of 
HIPERLAN/2 devices 

Mobile Terminal: device that communicates with an access point or with each other via a radio link. It is typically a 
user terminal 

Multicast: function that makes it possible for a group of MTs associated to an AP to receive the same information 

PHY mode: PHY mode corresponds to a signal constellation (Modulation alphabet) and a code rate combination 
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Radio cell: radio cell is the area covered by an access point or central controller. It is sometimes used as a term to 
describe an AP or CC and its associated terminals 

Radio Link Control sublayer: control plane of the DLC which offers transport services for the radio resource control, 
association control function and the DLC user connection control 

Radio Resource Control: group of control functions that use the services of the RLC. It controls the handling of radio 
resources 

Random Access CHannel: logical channel in the uplink of the MAC frame in which the MTs can send signalling data 
for the DLC or the RLC. It is transported in the random channel 

Random access Feedback CHannel: logical channel where the result of the access attempts to the random channel 
made in the previous MAC frame is conveyed 

Random CHannel: transport channel in the uplink of the MAC that carries the logical channels random access channel 
and association control channel. A contention scheme is applied to access it 

Random Access Phase: period of the MAC Frame where any MX can try to access the system. The access to this phase 
is based on a contention scheme 

Resource Grant: allocation of transmission resources by an access point or a central controller 

Resource Request: message from a terminal to an access point or central controller in which the current buffer status is 
conveyed to request for transmission opportunities in the uplink or direct link phase 

Sector antenna: term is used to describe if an access point or central controller uses one or more antenna element 

Transport channel: basic element to construct PDU trains. Transport channels describe the message format 

Uplink phase: part of the MAC frame in which data is transmitted from mobile terminals to an access point or a central 
controller 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

RxBoW Receivers BoW 

TxBoW Transmitters BoW 

I Concatenation of parameters 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ACF Association Control Function 

ACH Access feedback CHannel 

AP ID Access Point IDentifier 

AP Access Point 

APC Access Point Controller 

APT Access Point Transceiver 

ARP Antenna Reference Point 

ARQ Automatic Repeat Request 

BCH Broadcast CHannel 

BE Business Extension 

CC Central Controller 

CL Convergence Layer 

DCC DLC user Connection Control 

DCCH Dedicated Control CHannel 

DBS Data Encryption Standard 

DFS Dynamic Frequency Selection 

DiL Direct Link 
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DL DownLink 

DLC Data Link Control 

DM Direct Mode 

DUC DLC User Connection 

EC Error Control 

FCA Fixed Capacity Agreement 

FCCH Frame Control CHannel 

FCH Frame CHannel 

FSA Fixed Slot Allocation 

H/2 HIPERLAN type 2 

HE Home Extension 

HMAC Hash based Message Authentication Code 

HMSC High level MSC 

IV Initialization Vector 

LCCH Link Control CHannel 

LCH Long transport CHannel 

LSB Least Significant Bit 

MAC ID MAC IDentifier 

MAC Medium Access Control 

MD5 Message Digest #5 

MSB Most Significant Bit 

MSC Message Sequence Chart 

MT Mobile Terminal 

MT ID Mobile Terminal IDentifier 

NAI Network Access Identifier 

NET ID NET work IDentifier 

NOP ID Network Operator IDentifier 

NW NetWork 

OAP Optional in the AP 

OMT Optional in the MT 

PDU Protocol Data Unit 

PHY Physical layer 

PR Present 

RBCH RLC Broadcast CHannel 

RLC Radio Link Control 

RRC Radio Resource Control 

RSS Received Signal Strength 

SAP Service Access Point 

SCH Short transport CHannel 

SSK Session Secret Key 

TS Technical Specification 

UL UpLink 

UOA Use Omni Antenna 

WCC Wireless Congestion Control 



Overview 



The present document describes the basic RLC functions for the Association, Radio Resource Control and DLC User 
Connection Control between HIPERLAN/2 devices. It consists of functions and message formats for the AP and MT 
side. An overview of HIPERLAN/2 is given in TR 101 683 [21] and detailed description of the DLC basic transport 
functions is given in TS 101 761-1 [5]. It is recommended that TR 101 683 [21] and TS 101 761-1 [5] have been read 
before reading the present document. 



4.1 



BRAN HIPERLAN/2 Protocol Stack 



The HIPERLAN/2 basic protocol stack on the AP side and its functions are shown in figure 1 . It consists of the PHY 
layer on the bottom, the DLC layer in the middle (including RLC sublayer) and one or more convergence layers on top. 
The scope of HIPERLAN/2 standard end at the upper end of the CL on top of which higher layers are located. 
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Control Plane 



User Plane 



One instance per MAC-ID 



One instance per AP 

(if several transceivers (APIs) 

per AP, one instance per APT 



Higher Layers 



Convergence Layer 
DLC Control SAP DLC User SAP 



Radio Linl< Control sublayer 




Data Link Control - 

Basic Data Transport Function 



Error Control 



Medium Access Control 



Physical Layer 



Scope of 

HIPERLAN/2 

standards 



Figure 1 : BRAN HIPERLAN/2 protocol stack in the AP/CC 

The HIPERLAN/2 basic protocol stack on the MT side and its functions are depicted in figure 2. The difference to the 
model of the AP is that it contains only one RLC entity. 



Control Plane 



User Plane 



One instance per MAC ID 



Higher Layers 
CL SAPs 



Convergence Layer 
DLC Control SAP DLC User SAP 



Radio Link Control sublayer 




Data Link Control - 

Basic Data Transport Function 



Error Control 



Medium Access Control 



Physical Layer 



Scope of 

HIPERLAN/2 

standards 



Figure 2: BRAN HIPERLAN/2 protocol stack in the MT 

The present document is confined to the definition of the highlighted part shaded in grey, the RLC sublayer. It describes 
mainly the RLC messages and their format. 
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4.2 Functional Entities of RLC sublayer 

The division of functional entities of RLC sublayer is informative. From the perspective of functionality they have been 
divided to four groups in this specification: 

• Association Control; 

• Radio Resource Control; 

• DLC User Connection Control; 

• Basic RLC transport machine. 

The Association Control contains the functionality and the messages that are needed for establishing and releasing 
association, including Key Management and Authentication. Additionally, the broadcast and multicast group join and 
leave functions are included in Association Control. 

The Radio Resource Control contains the functionality and the messages of Dynamic Frequency Selection, Transmission 
Power Control, different kind of Handovers, Power Saving, MT_Alive and MT_Absence functions. The DLC User 
Connection Control contains the functionality and the messages of connection Setup, Modify, Reset and Release 
between AP/CC and MT (centralized mode) and between MTs (direct mode). 

4.3 Usage of DLC logical and transport channels for RLC 
messages 

The logical and transport channels of HIPERLAN/2 are described in [5]. The uplink and downlink RLC messages use 
the locical channels DCCH or RBCH. DCCH and RBCH use the transport channels SCH or LCH for downlink 
communication. The logical channel DCCH use the transport channels SCH, LCH or RCH for uplink communication. 

4.4 Transfer Syntax of RLC 

The transfer syntax of the RLC PDUs is described in annex A. The usage of the first octet in all SCH PDUs and the 
three most significant bits of octet three in Uplink SCHs are described in [5]. The first octet and the four most significant 
bits in octet two of the LCH PDUs are defined in [5]. The Most Significant Bit (MSB) is always on the left end of the 
field and therefore not shown separately in the tables in the annex. 

If a parameter is longer than one octet but is contained within one PDU, the most significant bit shall be placed in the 
octet with the lowest octet number of the octets containing the parameter and in the bit with the highest bit number. The 
least significant bit shall be placed in the octet with the highest octet number of the octets containing the parameter and 
in the bit with the lowest bit number. 

If a parameter is longer than one PDU, the most significant bit shall be placed in the PDU that is sent first and follow the 
rules given above with the exception that it is the least significant bit of the first part of the parameter that takes the place 
of the least significant bit of the whole parameter. The first and subsequent PDUs except the last one are completely 
filled. The least significant bit of the parameter shall be placed in the PDU that is sent last and follow the rule given 
above with the exception that it is the most significant bit of the last part of the parameter that takes the place of the most 
significant part. 

Table 1 : Transfer syntax format of the RLC SCH in Downlink 





8 


1 7 1 6 


1 5 1 4 1 3 1 2 


1 


Octet 1 


Defined in DLC TS 


Octet 2 


IVISB 




RLC SCH PDU type 




Octet 3 


IVISB 


EXTENSION-TYPE 


1 MSB RLC DATA 




Octet 4 


IVISB 




RLC DATA 






Octet 7 
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Table 2: Transfer syntax format of the RLC SCH in UpLink and RCH 





8 1 7 1 6 


1 5 1 4 1 3 


1 2 1 1 


Octet 1 


Defined in DLC TS 


Octet 2 


IVISB 


RLC SCH PDU type 




Octet 3 


Defined in DLC TS 


1 MSB EXTENSION-TYPE 


1 MSB RLC DATA 


Octet 4 


IVISB 


RLC DATA 






Octet 6 


Octet 7 


MAC ID 



Table 3: Transfer syntax format of the RLC LCH in Uplink and Downlink 





8 1 7 


6 1 


5 1 4 1 3 1 2 


1 1 


Octet 1 


Defined in DLC TS 


MSB 


Sequence number 




Octet 2 


Sequence nunnber 


1 MSB EXTENSION-TYPE 


1 Future use 


Octet 3 


MSB 


RLC LCH PDU type 




Octet 4 


MSB 


RLC DATA 








Octet 51 







4.5 Sequencing of RLC messages 

The high level MSCs, MSCs and the SDL diagrams define the sequences of the RLC messages. 

The basic principle of sequencing shall be that a new message from a node shall be sent after that a reply to the last 
message has been received. 

An important exception from the basic sequencing rule shall be the following: Retransmission of the same message may 
be done in two ways. One way shall be according to the basic rule. The second way shall be that the (same) message is 
transmitted several times without waiting for a reply between the retransmission occasions. 

For timer values that are longer than shortest timer value, an extra reply message shall be used supervised by an extra 
timer with the shortest timer value. The reason for this method is minimize the retransmission time. 

4.6 Message Sequence Charts of RLC 

The Message Sequence Charts (MSCs) of RLC PDU exchanges are shown in the corresponding chapters. Only the 
normal behaviour is defined in the MSCs. 

An MSC consists of messages being exchanged between peers of the system. The messages contain parameters that are 
defined by ASN.L The parts that are used in the RLC MSCs are RLC and environment instances in the MT and also 
RLC and environment instances in the AP. The environment is usually one of the informative function groups ACF, 
RRC or DUC, but may also be something else. 

4.7 Abstract Syntax Notation one of the RLC PDUs 

The mandatory and optional fields of the RLC PDUs are described with Abstract Syntax Notation one (ASN.l). The 
description is in annex B. 

4.8 The text style of RLC PDUs and parameters in RLC TS text 

The RLC PDUs are always written with capital letters and an underscore between the words. They are normally called 

messages. 

Example: RLC_MAC_ID_ASSIGN, RLC_LINK_CAPABILITY_ACK 
The parameters of RLC PDUs (messages) are written with small italic letters and there is a slash (-) between the words. 
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Example: duc-ext-ind, sleep-interval 



When an abbreviation, which is also used as a parameter is mentioned in text, the format of abbreviation is used (not the 
format of parameters). 

Example: MAC ID, AP ID 

The message exchanges that belong to one function are often called procedures. The functions and procedures are 
written in the following way: The first letter is a capital letter and the rest are small letters. 

Example: Association, MT_Alive 

4.9 Mandatory and Optional functions in the RLC TS 

The RLC TS contains mandatory and optional functions at different levels. For functions that are stated as mandatory, 
optional and mandatory subfunctions, messages and parameters can be defined. 

Functions, subfunctions, messages and parameters that are stated as optional for the RLC TS may be set as mandatory in 
extension documents or other documents referring to the RLC TS. 

Every function, subfunction, message or parameter that is optional to implement in order to follow the RLC TS is 
marked with an "OAP" or "OMT" in the present document, depending on whether it is optional in the MT or the AP. All 
functions, subfunctions, messages and parameters that are not marked are mandatory to implement. 

Functions, subfunctions, messages and parameters that can be selected or not at a particular occasion are negotiated at 
that occasion and the negotiation is specified in the present document in MSCs, ASN.ls, and SDLs. 

Example: The Encryption startup PDUs are mandatory to implement, but optional to use. The decision of the 

use is made by the AP. 



5 RLC Services 

5.1 Services supporting ACF (Association Control Function) 
5.1.1 Association 

During the Association procedure, the AP allocates a locally unique MAC ID [5] for the requesting MT. 
The Association procedure consists of the following procedures: 

RBCH Association; 

MAC ID Assignment; 

Link Capability Negotiation; 

Encryption Startup; 

Authentication; 

DM Common Key Distribution (GMT/GAP); 

Info Transfer. 
The order of the procedures is shown in the following high level Message Sequence Chart. 
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Diagram 1 : HMSC of the Association procedure 



MSC Association 



1(1) 



MT DISASSOCIATED FROM AP 



RBCH Association 



RBCHAssociation 
_Request 



l\/IAC_ld_Assignment 



LinkCapability 



Encryption_Startup 



Authentication 



DI\/l_Common_Key_ 
Distribution 



Info Transfer 



IVIT ASSOCIATED TO AP 
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5.1.1.1 RBCH Association 



The AP shall send the RLC_RBCH_ASSOCIATION message periodically. The number of frames between periodic 
transmission is outside the scope of the standard. The AP shall send the RLC_RBCH_ASSOCIATION message, when 
requested by the MT with RLC_RBCH_ASSOCIATION_REQ message. The MT shall request the 
RLC_RBCH_ASSOCIATION message, if the MT has not received the periodically sent message. 

If the c-u-g in the RLC_RBCH_ASSOCIATION message indicates that the group is closed, the MT should compare the 
Network Operator ID (NOP ID) to the preferred NOP IDs in the MT before the MT sends RLC_MAC_ID_ASSIGN 
message. The MT should associate to a group that is included in the MT's NOP ID list. If the c-u-g of the AP indicates 
an open group the MT may continue the Association procedure, but the MT shall compare the CL-ID first. 

NOTE: The allocation of the global part of the NOP ID is managed by ETSI. The allocation of the local part of 
the NOP ID is outside of scope of the present document. The network may be set up without having a 
NOP ID for APs. 

If none of the convergence-layer-IDs sent in the RLC_RBCH_ASSOCIATION message is supported by the MT, it shall 
not continue the Association. If one or more of the convergence-layer-IDs sent in the RLC_RBCH_ASSOCIATION 
message is supported by the MT, it may continue the Association. 

If the MT decides to continue the association procedure, the MT shall send the RLC_MAC_ID_ASSIGN message to the 
AP. 
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Diagram 2: RBCH Association 



MSC RBCH Association 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



MT disassociated from AP 



(/\CF- 



ACF_rbcli_association_ind 
RBCH-ASSOCIATION-ARG) 



(A(^-RBCH-ASSOCIATION-ARG) 



RLC RBCH ASSOCIATION 



{network-operator-id, 
cl-vid-list} ) 



ACF_rbch_association_req 



RLC RBCH ASSOCIATION received 



Diagram 3: RBCIH Association Request 



MSC I{BCH_Association_Request 





ACF_rbch_a ffiociationreq_ieq 






{ACF-RBCI 


[-ASSOCIATTON-REQ-ARG ) 


R]jC_RBCH_ASSOCIATION_REQ 


ACF_r bch_associa tionieq_iid 




T_rlx h_ association_req 


7 


(ap-id, 
net- id, 
mac- id 0) 




\ 




(ACF-RBCH-ASSOCIATION-REQ-ARG ) 










ACF_rbch_association_req 








RLC RBCH ASSOCIAHON 


( ACF-RBCH-ASSOCIATION-ARG) 






-^ 








( {retwark-opa-ator-id, 
cl-vid-list)) 




AC F_rbch_a ssoc iatic 


n_ind 


















( ACF-RBCH-ASSOCIATICN-ARG) 






Cteck 




Na \TOik_operator_ID 















Net\TOrk_Opaator_ID_and_CUD_rec eived 



Table 4: RLC-RBCH-ASSOCIATION 



RLC-RBCH-ASSOCIATION-ARG ::= SEQUENCE { 



ric-pdu-type 

network-operator-id 

cl-vid-list 



RLC-LCH-PDU-TYPE, 
NETWORK-OPERATOR-ID OPTIONAL, 
CL-VID-LIST} 
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Table 5: RLC-RBCH-ASSOCIATION-REQ (OMT) 



RLC-RBCH-ASSOCIATION-REQ-ARG ::= SEQUENCE { 



ric-pdu-type RLC-SCH-PDU-TYPE, 

ap-id AP-ID, 

net-id NET-ID, 

mac-id IVIAC-IDO} 



5.1.1.2 MAC ID Assignment 

The MT shall request a MAC ID from the AP by sending RLC_MAC_ID_ASSIGN message. The parameter magic is a 
temporary identifier for the MT and should be a random number. The parameters mac-id and mac-idl of the 
RLC_MAC_ID_ASSIGN message shall be set to zero. The parameter mac-id of the RLC_MAC_ID_ASSIGN_ACK 
message shall contain the MAC ID allocated by the AP. The RLC_MAC_ID_ASSIGN_ACK message shall be sent via 
RBCH. 

NOTE: The mac-id in RLC_MAC_ID_ASSIGN_ACK is doubled to decrease the risk of errors in the mac-id. 

If the AP does not allocate a MAC ID for the MT, the AP shall send the RLC_MAC_ID_ASSIGN_NACK message. 
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Diagram 4 MAC ID Assignment 



MSC MAC_ld_Assignment 

MT ENV I 



MT RLC 



AP RLC 



AP ENV 



RLC_RBCH_ASSOCIATION_Received 



ACF_macJd_assign_req 



I {magic, 
ric-version, 
mac-id} 



T_macjd_assign 



ACF_macJd_assign_cnf 



Open RLC 
DLCC 



{magic, 
mac-id} 



RLC_IVIAC_ID_ASSIGN 



1 {magic, 
rIc-version, 
mac-id 0} 



F!LG_MAG_ID_ASSIGN_ACK 



I { 



( {magic, 

mac-id, 

mac-id1} 



ACF_macJd_assignJnd 



magic, 
rIc-version, 
mac-id} 



AGF_macJd_assign_rsp 



{magic, 
T_macjd_assign_ack mac-id} 



mac-id repeated for 
safety reasons 



Open RLC 
DLCC 



MAC_ID_Assigned 



Table 6: RLC-IVIAC-ID-ASSIGN 



RLC-MAC-ID-ASSIGN-ARG ::= SEQUENCE { 



ric-pdu-type 
magic 
rIc-version 
mac-id 



RLC-SCH-PDU-TYPE, 
IVIAGIC, 

RLG-VERSION, 
IVIAG-IDO} 



Table 7: RLC-l\flAC-ID-ASSIGN-ACK 



RLG-MAG-ID-ASSIGN-AGK-ARG ::= SEQUENCE ■ 



ric-pdu-type 
magic 
mac-id 
mac-idi 



RLC-SCH-PDU-TYPE, 

iVIAGIC, 

iVIAC-iD, 

iVIAC-ID } 



Table 8: RLC-IVIAC-ID-ASSIGN-NACK 



RLC-MAC-ID-ASSIGN-ACK-ARG ::= SEQUENCE ■ 



ric-pdu-type RLC-SCH-PDU-TYPE, 
magic iVIAGIC} 



5.1.1.3 Link Capability 

The MT shall propose link capability alternatives to the AP in the RLC_LINK_CAP ABILITY message. The AP shall 
select from the link capability alternatives proposed by the MT and add its own link capabilities to the 
RLC_LINK_CAPABILITY_ACK message, which shall then be sent to the MT. 

If the MT accepts the parameters in the RLC_LINK_CAPABILITY_ACK message, it shall proceed with the 
Association. Whether the Association continues with Encryption startup. Authentication, DM Common Key distribution. 
Info Transfer or goes directly to the associated state, shall be controlled by parameters in the 
RLC_LINK_CAPABILITY_ACK message. 
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Diagram 5: Link Capability Negotiation 



MSC Link_Capability 

MT ENV 



MT RLC 



AP RLC 



AP ENV 



ACF_link_capability_req 



(ACF-LINK-CAPABILITY-ARG 
TJinkcapability 



( ACF-LINK-CAPABILITY-ACK-ARG ] 



MAC_ID_Assigned 



RLC LINK CAPABILITY 



({dic-version, 

ric-version, 

d-vid-list, 

rss-value, 

support64qam, 

freq-band, 

direct-mode-cap, 

cyclic-prefix, 

support-fca, 

suppcrt-fsa, 

time-gap-ach-uplink, 

Ino-cap, 

cc-ho-cap, 

duty -cycle, 

arq-delay-rx, 

arq-delay-tx, 

authentication -encryption -list, 

dm-attributes} 



RLC LINK CAPABILITY ACK 



ACF_link_capability_cnf 



( {die -version-selected, 

rIc-version -selected, 

rss-value, 

apt-ad dress-lengtin, 

support 64qam, 

freq-band, 

direct-mode-cap, 

dm -use-common-key, 

cyclic-prefix, 

support-fca, 

support-fsa, 

cc-lno-cap, 

arq-delay-rx, 

arq-delay-tx, 

autln-encr-selected, 

dm-attributes} ) 



T_mac_id_assign_ack 



ACFJink_capability_ind 



(ACF-LINK-CAPABILITY-ARG 



ACFJink_capability_rsp 



'ACF-LINK-CAPABILITY-ARG 



TJInk_capabillty_ack 



LinkAgreed 
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Table 9: RLC-LINK-CAP ABILITY 



RLC-LINK-CAPABILITY-ARG ::= 


SEQUENCE! 


ric-pdu-type 


RLC-LCH-PDU-TYPE, 


dic-version 


DLC-VERSION, 


ric-version 


RLC-VERSION, 


cl-vid-list 


CL-VID-LIST, 


rss-value 


RSS-VALUE, 


support64QAM 


SUPPORTED64QAM, 


freq-band 


FREQUENCY-BAND, 


direct-mode-cap 


DIRECT-MQDE-CAP, 


cyclic-prefix 


CYCLIC-PREFIX, 


support-fca 


SUPPQRTED-FCA, 


support-fsa 


SUPPQRTED-FSA, 


ho-cap 


HQ-CAP, 


cc-lio-cap 


CC-HQ-CAP, 


time-gap-ach-uplinl< 


TIME-GAP-ACH-UPLINK, 


duty-cycle 


DUTY-CYCLE, 


arq-delay-rx 


ARQ-DELAY, 


arq-delay-tx 


ARQ-DELAY, 


authentication-encryption-list 


AUTHENTICATION-ENCRYPTION-LIST, 


dm-attributes 


DM-ATTRIBUTES OPTIONAL - (OMT/OAP) - } 



Table 10: RLC-LINK-CAPABILITY-ACK 



RLC-LINK-CAPABILITY-ACK-ARG ::= SEQUENCE { 


rIc-pdu-type 


RLC-LCH-PDU-TYPE, 


dic-version-selected 


DLC-VERSION, 


ric-version-selected 


RLC-VERSION, 


rss-value 


RSS-VALUE, 


apt-address-length 


APT-ADDRESS-LENGTH, 


support640AM 


SUPPQRTED64QAM, 


freq-band 


FREQUENCY-BAND, 


send-mt-id 


SEND-MT-ID, 


direct-mode-cap 


DIRECT-MODE-CAP, 


dm-use-common-key 


DM-USE-COMMON-KEY, 


cyclic-prefix 


CYCLIC-PREFIX, 


support-fca 


SUPPQRTED-FCA, 


support-fsa 


SUPPQRTED-FSA, 


cc-ho-cap 


CC-HQ-CAP, 


arq-delay-rx 


ARQ-DELAY, 


arq-delay-tx 


ARQ-DELAY, 


auth-encr-selected 


AUTH-ENCR-INFO, 


dm-attributes 


DM-ATTRIBUTES OPTIONAL - (OMT/OAP) - } 



5.1 .1 .4 Encryption startup 

The MX shall calculate and send its public Diffie-Hellman value to the AP. The AP shall also calculate and send its 
public Diffie-Hellman value to the MX. Both MX and AP shall calculate encryption keys based on the received public 
Diffie-Hellman values. How the public Diffie-Hellman values and the encryption keys shall be calculated are described 
in subclause 5.1.2.5.1. 
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Diagram 6: Encryption Startup procedure 



MSC Encryption_Startup 

MT ENV 



MT_RLC 



AP_RLC 



AP ENV 



Linkagreed 



ACF_key_exchange_mt_req 



({mac-id, 
mt-dh-public-value} ) 



T_key_exchange_mt 



ACF_key_exchange_ap_cnf 



( {mac-id, 

ap-dii-public-value}) 



RLC KEY EXCHANGE MT 1 



({mt-dln-public-value-1 } ) 
RLC_KEY_EXCHANGE_MT_2 



({mt-dln-public-value-2} ) 



RLC_KEY_EXCHANGE_AP_1 



TJink_capability_ack 

ACF_key_exclnange_mt_ind 

({mac-id, 

mt-dh-public-value} ) 

ACF_key_exchange_ap_rsp 

■* 

( {mac-id, 

ap-dii-pubiic-vaiue}) 



( {ap-dh-public-value-1}) 
RLC_KEY_EXCHANGE_AP_2 



T_key_exciiange_ap 



( {ap-dh-public-value-2}) 



Encryptionactive 



Table 11 : RLC-KEY-EXCHANGE-l\flT-1 



RLC-KEY-EXCHANGE-MT-1-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE, 
mt-dh-public-value-1 DH-PUBLIC-VALUE-HALF} 



Table 12: RLC-KEY-EXCHANGE-l\flT-2 



RLC-KEY-EXCHANGE-MT-2-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE, 

mt-dh-public-value-2 DH-PUBLIC-VALUE-HALF } 



Table 13: RLC-KEY-EXCHANGE-AP-1 



RLC-KEY-EXCHANGE-AP-1-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE, 

ap-dh-public-value-1 DH-PUBLIC-VALUE-HALF } 



Table 14: RLC-KEY-EXCHANGE-AP-2 



RLC-KEY-EXCHANGE-AP-2-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE, 

ap-dh-public-value-2 DH-PUBLIC-VALUE-HALF } 
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5.1.1.5 Authentication 



5.1.1.5.1 General 



The scope for the authentication is Hmited to the local HIPERLAN/2 wireless LAN. Higher level or remote 
authentication, for example user authentication through the Internet to corporate network, is outside the scope of the 
present document. 

Mutual authentication is supported. MT authentication controls the access of the MT to the connected fixed network. If 
the authentication of the MT fails no access shall be granted to the MT. 

NOTE: AP authentication helps a MT to detect false APs. 

The AP shall decide if MTs are allowed to access the network without authentication, and the MT may decide to cancel 
the access attempt to a network if AP authentication fails or is not supported. 

5.1.1.5.2 Authentication procedures 

There are six possible types of identifiers for the authentication key, the signalling related to these are shown in the 
HMSC for authentication.. 

There are two different types of authentication protocols, pre-shared key based and RSA signature based, see 
subclause 5.1.2.6.2. 



Diagram 7: HMSC of the Authentication procedure 



MSC Authentication 



1(1) 




5.1.1.5.3 Authentication key identifier alternatives 

5.1.1.5.3.1 General 

The MT can fetch the authentication key of the AP based on all or parts of the Network Operator (NOP ID), network 
(NET ID), and AP (AP ID) identities that are sent over the broadcast channels. 

Each MT shall be assigned an authentication key identifier that should be presented to the connected AP at association. 
The AP shall use it to retrieve the key related to the access. The identifier can be of different types. One of the identifier 
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types is mandatory to implement (free to choose), the remaining ones are optional. The MT authentication key identifier 
should be protected by encryption during transfer to the AP. 

5.1.1.5.3.2 IEEE address as authentication key identifier (Conditional OAP/OMT, see 5.1.1.5.3.1) 

This procedure shall use the 48-bit IEEE address [8] as authentication key identifier. The AP shall send a challenge to 
the MT as response. 

Diagram 8: Authentication IEEE 



MSC Authentication_IEEE 

MT ENV 



MT_RLC 



AP_RLC 



Encryption_active 



ACF_auth_mt_req 



({mac-id, 

mt_auth-id-type ieee, 
mt-auth-id {ieee}} ) 



Tauthentication 



RLC_AUTHENTICATION 

({more 0, 

mt-auth-id-type ieee, 
mt-auth-id-content {ieee}} ) 



— i>^ T key_exchange_ap 
— ^ TJinl<_capability_acl< 

ACF_auth_mt_ind 

({mac-id, 

mt-auth-id-type ieee, 
mt-auth-id {ieee}} ) 



AP ENV 



ACF_auth_mt_rsp 



RLC AUTHENTICATION MT 



({challenge-to-mt}) 



; {mac-id, 

challenge-to-mt}) 



T authentication mt 



ACF_auth_mt_cnf 



( {mac-id, 

challenge-to-mt}) 



ChallengeToMTReceived 



Table 15: RLC-AUTHENTICATION 



RLC-AUTHENTICATION-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-LCH PDU-TYPE, 


more 


MORE-AUTH, 


mt-auth-id-type 


MT-AUTH-ID-TYPE, 


mt-auth-id-content 


MT-AUTH-CONTENT } 



Table 16: RLC-AUTHENTICATION-MT 



RLC-AUTHENTICATION-MT-ARG ::= SEQUENCE { 



rIc-pdu-type 
challenge-to-mt 



RLC-LCH-PDU-TYPE, 
CHALLENGE } 
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5.1.1.5.3.3 Extended IEEE address as authentication key identifier (Conditional OAP/OMT, see 5.1.1.5.3.1) 

This procedure shall use the 64 bit extended IEEE address [9] as authentication key identifier. The AP shall send a 
challenge to the MT as response. 



Diagram 9: Authentication EXTJEEE 



MSC Authentication_ext_IEEE 

MT ENV I I MT RLC 



AP RLC 



AP ENV 



Encryptionactive 



ACF_auth_mt_req 



({mac-id, 

mt-auth-id-type ext-ieee, 
mt-auth-id {ext-ieee}} ; 



RLC AUTHENTICATION 



({more 0, 

mt-auth-id-type ext-ieee, 
mt-auth-id-content {ext-ieee}} ) 



Tauthentication 



RLC AUTHENTICATION MT 



({challenge-to-mt}) 



ACF auth mt cnf 



( {mac-id, 

challenge-to-mt}) 



-^ T_key_exchange_ap 
\/ TJink_capability_ack 

ACF auth mt ind 



({mac-id, 

mt-auth-id-type ext-ieee, 
mt-auth-id {extjeee}} 



ACF_auth_mt_rsp 



( {mac-id, 

challenge-to-mt}) 



T authentication mt 



ChallengeToMTReceived 



5.1 .1 .5.3.4 Network access identifier as authentication key identifier (Conditional OAP/OMT, see 
5.1.1.5.3.1) 

This procedure shall be used when the NAI (network access identifier) [10] is used as authentication key identifier. The 
AP shall send a challenge to the MT as response. 
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Diagram 10: Authentication NAI 



MSC Authentication_Net_Acc_ld 

MT_ENV I I MT_RLC 



alt 



AP_RLC 



AP ENV 



Encryptionactive 



ACF_auth_mt_req 



({mac-id, 

mt-auth-id-type net-acc-id, 
ml-auth-id {nel-acc-id}} 



mt_auth_id > 46 octets 



RLC AUTHENTICATION 



({more 1 , 

mt-auth-id-type net-acc-id, 
mt-auth-id-content {net-acc-id}} ) 

RLC^AUTHENTICATION 



mt_autiijd <= 46 octets 



({more 0, 

mt-autii-id-type net-acc-id, 

rnt-auth-jdjcontent {net^-acc-Jd}} 

RLC AUTHENTICATION 



({more 0, 

mt-auth-id-type net-acc-id, 
mt-auth-id-content {net-acc-id}} ) 



T authentication 



RLC AUTHENTICATION MT 



({challenge-to-mt}) 



ACF_auth_mt_cnf 



( {mac-id, 

challenge-to-mt}) 



—iK, T_key_exchange_ap 
-^ TJink_capability_ack 

ACF_auth_mt_ind 



({mac-id, 

mt-auth-id-type net-acc-id, 

mt-auth-id {net-acc-id}} ) 

ACF_auth_mt_rsp 



( {mac-id, 

challenge-to-mt}) 

T authentication mt 



ChallengeToMTReceived 



5.1.1.5.3.5 Distinguished name as on autlnentication key identifier (Conditional OAP/OMT, see 5.1.1.5.3.1) 

This procedure shall be used if distinguished name [11] is the MT authentication key identifier. The AP shall send a 
challenge to the MT as response. 
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Diagram 11: Authentication Distinguished name 



MSC Authentication_dist_name 



Encryption_active 



ACF_auth_mt_req 



({mac^d, 

mt-auth-id-typs da-name, 
mt-auth-id { di st-name } } ) 



mt_ailh_id > 46 octets 



mt_aith_id<=46 cctets 



T_authentication 



AC F_auth_mt_cnf 



{ { mac- id, 

challenge-to- mt}) 



RLC_AUTHENri CATI ON 



( { more 1 , 

mt-auth-id-type dist-name, 
mt-auth-id-coilait (dia-name)) ) 

RLC_AU1HENTI CATICN_ 2 



\/ T_key_exchai^e_ap 
—\if T_link_ c^abiJit y_ac k 



( { mere 0, 

mt-auth-id-lype dist-name, 
mt- aiith -id -c orient (dia-name)) ) 



RLC_AUTHENri CATI ON 



( { more 0, 

mt-auth-id-type dist-name, 
mt-auth-id-coilent (dia-name)) ) 



T_key_excharge_ap 
T_link_ ci^jabilit y_ac k 



ACF_ailh_mt_ind 



({mac -id, 

mt-auth^d-type dist-name, 
mt-auth^d {dist-nane ) ) ) 



ACF_auth_mt_rsp 



( (mac -id, 

challenge- to^nt)) 



R]jC_AUrHENTICATION_MT 



T_a uthenticat iai_mt 



( (challenge-to-mt)) 



Chal lai^_To_ Mr_Received 



5.1 .1 .5.3.6 Compressed type as authentication key identifier (Conditional OAP/OMT, see 5.1 .1 .5.3.1 ) 

This procedure shall be used if the compressed type is the MT authentication key identifier. The compressed type can be 
used if the available authentication key identifier is so long that it is not possible to carry in the defined RLC messages. 
The compressed authentication key identifier is calculated as follows: compressed-authentication-key- 
identifier=MD5(available_authentication_key_identifier). The AP shall send a challenge to the MT as response. 
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Diagram 12: Authentication Compressed 



MSC Authentication_Compressed 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



Encryption_active 



I {mac-id, 
mt-auth-id-type compressed, 
mt-auth-id {compressed}} ) 



ACF_auth_mt_req 



T authentication 



ACF auth mt cnf 



( {mac-id, 

challenge-to-mtj 



RLC AUTHENTICATION 



( {more 0, 
mt-auth-id-type compressed, 
mt-auth-id-content {compressecj}} 



RLC AUTHENTICATION MT 



{{challenge-to-mt} 



Challenge_To_MT_Received 



-^ T_key_exchange_ap 
-X TJink_capability_ack 

ACF auth mt ind 



{mac-id, 

mt-auth-id-type compressed, 

mt-auth-id {compressed}} ) 

ACF_auth_mt_rsp 



( {mac-id, 

challenge-to-mtj 



^^ T authentication mt 



5.1 .1 .5.3.7 Generic type as authentication key identifier (Conditional OAP/OMT, see 5.1 .1 .5.3.1 ) 

This procedure shall be used if the generic type is the MT authentication key identifier. The generic type is a non- 
structured octet string. The AP shall send a challenge to the MT as response. 
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Diagram 13: Authentication Generic 



MSC Authentication_Generi 

MT ENV I MT RLC 



alt 



AP RLC 



AP ENV 



Encryptionactive 



ACF_auth_mt_req 



{mac-id, 

mt-auth-id-type generic, 
ml-auth-id {generic}} ) 



mt_authjd longer ttian 46 octets 



mt_auth id up to 46 octets 



^ 



T authentication 



ACF_auth_mt_cnf 



( {mac-id, 

challenge-to-mt} 



LC AUTHENTICATION 



{mo re 1, 

mt-autti-id-type generic, 
mt-autti-id-content {generic}} 

RLC_AUTHENTICATION 



{more 0, 

mt-auth-id-type generic, 
mt-auth-id-co ntent {gen eric}} 



RLC_AUTHENTICATION 

{more 0, 

mt-auth-id-type generic, 
mt-auth-id-content {generic}} 



RLC_AUTHENTICATION_MT 



{(;hallenge-to-mt} 



-^ T_key_exchange_ap 
-^ TJink_capability_ack 

ACF auth mt ind 



{mac-id, 

mt-auth-id-type generic, 
mt-auth-id {generic}} ) 

ACF_auth_mt_rsp 



( {mac-id, 

challenge-to-mt} 

Tauthenticationmt 



Challenge_To_MT_Received 



5.1 .1 .6 Authentication based on different key types 

5.1.1.6.1 Authentication with pre-shared l^ey (Conditional OAP/OMT, see 5. 1 . 1 .5.3. 1 ) 

The MT shall send a challenge to the AP as well as the calculated response. How the response shall be calculated is 
described in subclause 5.1.2.6.3. 



£75/ 



33 



ETSI TS 101 761-2 VI. 1.1 (2000-04) 



Diagram 14: Authentication AP Pre-shiared 



MSC Authentication_AP_Pre_Shared 

MT ENV MT RLC 



AP RLC 



AP ENV 



; {mac-id, 
challenge-to-ap, 
mt-response{pre-shared}) 



ACF_auth_ap_req 



T_authetication_ap 



Challenge_To_MT_Received 



RLC AUTHENTICATION AP 



( {challenge-to-ap, 
mt-response-1} ) 



T authentication mt 



ACF_auth_ap_ind 



( {mac-id, 
challenge-to-ap, 
mt-response{pre-shared) 



Challenge_To_AP_Received 



Table 17: RLC-AUTHENTICATION-AP-1 



RLC-AUTHENTICATION-AP-1-ARG ::= SEQUENCE { 



ric-pdu-type 

challenge-to-ap 

mt-response-1 



RLC-LCH-PDU-TYPE, 
CHALLENGE, 
AUTH-RESP0NSE-PART1 } 



Table 18: RLC-AUTHENTICATION-AP-2 



RLC-AUTHENTICATION-AP-2-ARG ::= SEQUENCE { 



rIc-pdu-type 
mt-response-2 



RLC-LCH-PDU-TYPE, 
AUTH-RESP0NSE-PART2 



Table 19: RLC-AUTHENTICATION-AP-3 



RLC-AUTHENTICATION-AP-3-ARG ::= SEQUENCE { 



rIc-pdu-type 
mt-response-2 



RLC-LCH-PDU-TYPE, 
AUTH-RESP0NSE-PART2 } 



The AP shall send the calculated response to the MT. How the response shall be calculated described in 

subclause 5.1.2.6.4. 
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Diagram 15: Authentication Acl< Pre-shiared 



MSC Authentication Acl< Pre Sliared 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



Challenge_To_AP_Received 



ACF_auth_ap_rsp 



Tauthenticationap 



( {mac-id, 

RLC_AUTHENTICATION_ACK_1 ap-response{pre-shared }) 



[ {ap-response-2}) ■- Tauthenticationack 



ACF_auth_ap_cnf 



( {mac-id, 

ap-response{pre-shared }}) 



Autiienticated 



Table 20: RLC-AUTHENTICATION-ACK-1 



RLC-AUTHENTICATION-ACK-1-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE, 

ap-response-2 AUTH-RESP0NSE-PART2 } 



Table 21 : RLC-AUTHENTICATION-ACK-2 



RLC-AUTHENTICATION-ACK-2-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE, 
ap-response-2 AUTH-RESP0NSE-PART2} 



Table 22: RLC-AUTHENTICATION-ACK-3 



RLC-AUTHENTICATION-ACK-3-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE, 

ap-response-2 AUTH-RESP0NSE-PART2} 



5.1.1.6.2 Authentication based on 512 bit RSA signature (Conditional OAP/OMT, see 
5.1.1.5.3.1) 

The MT shall send a challenge to the AP as well as the calculated response. How the response shall be calculated is 
described in subclause 5.1.2.6.4. 
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Diagram 16: Authentication AP RSA Signature 512 



MSC Authentication_AP_RSA_Signature_51 2 



MT ENV 



MT_RLC 



AP_RLC 



AP ENV 



ChallengeToMTReceived 



ACF_auth_ap_req 



({mac-id, 
challenge-to-ap, 
mt-respo nse{rsa-sig natures 12} 



RLC_AUTHENTICATI0N_AP_1 

* 

({challenge-to-ap, 
mt-response-1 } ) 

RLC AUTHENTICATION AP 2 



T authentication mt 



T„authentication_ap X ({mt-response-2} ) 



ACF_auth_ap_ind 



({mac-id, 
challenge-to-ap, 
mt-response{rsa-signature51 2}} 



ChallengeToAPRecelved 



The RLC_AUTHENTICATI0N_AP_1 and RLC_AUTHENTICATION_AP_2 messages are defined in 5.1.1.6.1. 

The AP shall send the calculated response to the MT. How the response shall be calculated is described in 
subclause 5.1.2.6.4. 

Diagram 17: Authientication Acit RSA Signature 512 



MSC Authentication_Ack_RSA_Signature_512 












MT_ENV 




MT_RLC 




AP_RLC 




AP_ENV 
































<{ Challenge_To_AP_Received \ 








T authentication ao 


RLC^AUTHENTICATI0N_ACK_1 ( 


ACF_auth_ap_rsp 








{mac-id, 
ap-response{rsa-signature512 }}) 




( {ap-response-2}) 
RLC_AUTHENTICATI0N_ACK_2 






( {ap-response-2}) 




Tauthenticationack 


ACF_auth_ap_cnf 


Zx 






( {mac-id, 
ap-response{rsa-signature512 }}) 










< Authenticated > 



















The RLC_AUTHENTICATION_ACK_l and RLC_AUTHENT1CAT10N_ACK_2 messages are defined in 5.1.1.6.1. 
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5.1 .1 .6.3 Authentication based on 768 bit RSA signature (Conditional OAP/OMT, see 
5.1.1.5.3.1) 

The MT shall send a challenge to the AP as well as the calculated response. How the response shall be calculated is 
described in subclause 5.1.2.6.4. 



Diagram 18: Authentication AP RSA Signature 768 



MSC Authentication_AP_RSA_Signature_768 

MT ENV I I MT RLC 



AP RLC 



Challenge_To_MT_Received 



ACF_auth_ap_req 



({mac-id, 
challenge-to-ap, 
mt-response{rsa-signature768 }} 



Tauthenticationap 



RLC_AUTHENTICATI0N_AP_1 



({challenge-to-ap, 
mt-respcnse-1} ) 

RLC_AUTHENTICATI0N_AP_2 



({mt-response-2} ) 
RLC AUTHENTICATION AP 3 



({mt-response-2} ) 



Tauthenticationmt 



ACF_auth_ap_ind 



AP ENV 



({mac-id, 
ctiallenge-to-ap, 
mt-response{rsa-signature768 }) 



Challenge_To_AP_Received 



The RLC_AUTHENTICATI0N_AP_1, RLC_AUTHENTICATION_AP_2 and RLC_AUTHENTICATION_AP_3 

messages are defined in 5.1.1.6.1. 

The AP shall send the calculated response to the MT. How the response shall be calculated is described in 
subclause 5.1.2.6.4. 
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Diagram 19: Authentication Acl< RSA Signature 768 



MSC Authentication_Ack_RSA_Signature_768 

MT ENV I I MT RLC 



AP RLC 



AP ENV 



C ha lie nge_To_A PR ece ived 







RLC_AUTHENTICAT!0N_ACK_1 












( {ap-response-2}) 




T authentication ap 

\/ 


RLC_AUTHENTICATI0N_ACK_2 


{ (ap-response-2}) 




ACF_auth_ap_cnf 






{mac-id, 
ap-response{rsa-signature768 }}) 





ACF_auth_ap_rsp 



{mac-id, 
ap-response{rsa-signature768 }}) 



"^^ T authentication acl< 



Authenticated 



The RLC_AUTHENTICATION_ACK_l and RLC_AUTHENTICATION_ACK_2 messages are defined in 5.1.1.6.1. 

5.1.1.6.4 Authentication based on 1 024 bit RSA signature (Conditional OAP/OMT, see 
5.1.1.5.3.1) 

The MT shall send a challenge to the AP as well as the calculated response. How the response shall be calculated is 
described in subclause 5.1.2.6.4. 
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Diagram 20: Authentication AP RSA Signature 1024 



MSC Authentication_AP_RSA_Signature_1 024 



MT ENV 



MT_RLC 



AP_RLC 



ACFauth ap_req 



Challenge_To_MT_Received 



RLC_AUTHENTICATI0N_AP_1 



({mac-id, 
challenge-to -ap, 

mt-response{rsa-signature1024 }} ) ({challenge-to-ap, 

mt-response-1} 



RLC_AUTHENTICATI0N_AP_2 



Tauthenticationap 



({mt-response-2}) 
RLC_AUTHENTICATI0N_AP_3 



({mt-response-2} ] 



C halle nge_To_A P_R ece ived 



T authentication mt 



ACF_auth_ap_ind 



AP ENV 



({mac-id, 
challenge-to-ap, 
mt-response{rsa-signature1024 }f 



The RLC_AUTHENTICATI0N_AP_1, RLC_AUTHENTICATION_AP_2 and RLC_AUTHENTICATI0N_AP_3 
messages are defined in 5. 1 . 1 .6. 1 . 

The AP shall send the calculated response to the MT. How the response shall be calculated is described in 
subclause 5.1.2.6.4. 
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Diagram 21 : Authentication Acl< RSA Signature 1024 



MSC Authentication_Ack_RSA_Signature_1 024 












MT_ENV 




MT_RLC 




AP_RLC 




AP_ENV 
































/ Challenge_To_AP_Received \ 








T authentication ao 


RLC_AUTHENTICATI0N_ACK_1 


ACF_auth ap_rsp 








( {mac-id, 
ap-response{rsa-signature1024 }}) 




( {ap-response-2}) 
RLC_AUTHENTICATI0N_ACK_2 


( {ap-response-2}) 
RLC_AUTHENTICATI0N_ACK_3 






( {ap-response-2}) 




Tauthenticationacl^ 


ACF_auth_ap_cnf 








( {mac-id, 
ap-response{rsa-signature1024 }}) 










< Authenticated > 

\ / 



















The RLC_AUTHENTICATION_ACK_l, RLC_AUTHENTICATION_ACK_2 and 
RLC_AUTHENTICATION_ACK_3 messages are defined in 5.1.1.6.1. 

5.1 .1 .7 DM Common Key Distribution (OAP/OMT) 

The AP shall inform the MT about the encryption algorithm, the KEY ID and common key that shall be used for direct 
mode encryption. The MT shall confirm that the encryption algorithm and that the direct mode encryption key have been 
received. 
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Diagram 22: DM Common Key Distribution 



MSC DM_Common_Key_Distribution 

MT ENV I I MT RLC 



AP RLC 



AP ENV 



MT_Associated_to_AP 



RLC_DM_COMMON_KEY_DISTR 



ACF_dm_common_key_distr_ind 



( {mac-id, 

dm-encr-alg, 

key-id, 

common -key}) 

ACF_dm_common_key_distr_rsp 



{dm-encr-alg, 

key-id, 

common-key}) 



({mac-id, 
dm-encr-aig, 
md5-on-key}) 



rlc_dm_common_key_distr_ai;k 



({dm-encr-aig, 
md5-on-key} 



ACF_dm_common_key_distr_req 



( {mac-id, 

dm-encr-aig, 

key- id, 

common-key}) 



T_dm_common_key_distr 



\/ TJink_capabiiity_ack 

jy T_key_exchange_ap 

\/ Tauthenticationack 

-^ T_dm_common_key_distr_ack 



ACF_dm_commonkey_distr_cnf 



({mac-id, 
dm-encr-alg, 
md5-on-key}) 



MT Associated to AP 



Table 23: RLC-DIVI-COIVIIVION-KEY-DISTR 



RLC-DM-COMMON-KEY-DISTR-ARG ::= SEQUENCE { 



ric-pdu-type 
dm-encr-alg 
key-id 
common-key 



RLC-LCH-PDU-TYPE, 
ENCR-INFO, 
KEY-ID, 
COMMON-KEY } 



Table 24: RLC-DI\fl-COMMON-KEY-DISTR-ACK 



RLC-DM-COMMON-KEY-DISTR-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type 
dm-encr-alg 
md5-on-key 



RLC-LCH-PDU-TYPE, 
ENCR-INFO, 
MD5-0N-KEY } 
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5.1 .1 .8 Info Transfer procedure (OAP/OMT, depends on CL and DLC) 

The MTs and AP/CC may use this function to exchange convergence layer or DLC layer information. 

In centralized mode (RLC messages sent over the DCCH in the uplink down link phase), the Info Transfer procedure is 
always initiated by the MT. Therefore, the MT shall use the RLC_INFO message and the AP/CC shall use the 
RLC_INFO_ACK message. The AP shall send the RLC_INFO_ACK as a response to the RLC_INFO message. 

In direct mode (RLC messages sent over the DCCH in the direct link phase), the Info Transfer procedure may be 
initiated by either a MT or the AP/CC. The MT or AP/CC receiving a RLC_INFO message shall send the 
RLC_INFO_ACK message as a response. 

Info Transfer procedure shall run at the end of the association phase. It may also run at any time after one MT has been 
associated. 

In case of multiple CLs the MT or AP/CC shall check the CL-ID in the RLC_INFO_ACK to associate the respond with 
corresponding request. 

During the association phase, several RLC_INFO messages may be sent in sequence. The number of messages depend 
from the supported convergence layers. 

The INFO-TYPE field in the RLCJNFO message indicates whether the RLC_INFO is a new RLC_INFO message or 
the retransmission of a non acknowledged, and already sent RLC_INFO message. 

The INFO-COUNT field is used in different ways in the association phase and outside the association phase. 

• In the association phase, the INFO-COUNT field is used to indicate to the peer entity the number of remaining 
RLC_INFO messages to be transmitted for the whole set of supported convergence layers during the association 
phase. 

• Outside of the association phase, the INFO-COUNT field is used so that the RLC_INFO_ACK can be associated to 
the corresponding request of a single Info Transfer procedure. When a MT or AP/CC sends a RLC_INFO_ACK 
message, it shall use the same INFO_COUNT as found in the RLCJNFO. When a MT or AP/CC sends a 
RLCJNFO message, it shall: 

Use the same INFO_COUNT as the previous RLCJNFO if it is running an error recovery process (timeout 
expired to get the RLC_INFO_ACK); 

Decrease the INFO_COUNT by one (compared to the previous RLCJNFO) if it is starting a new Info Transfer 
procedure. 



£75/ 



42 



ETSI TS 101 761-2 VI. 1.1 (2000-04) 



Diagram 23: Info Transfer 



MSC lnfo_Transfer 

MT ENV 



MT RLC 



AP RLC 



AP ENV 



Link_Agreed_or_Encryption_active_or_Authenticated 




RLCJNFO 



({info-count, 
info-type, 
cl-data, 
die-attributes} 



TJinl<_capability_ack 
T_key_exclnange_ap 
T_autlnentication_ack 

T_d mcom m on_key_d istrack 
Tnwsignaliing handover_ack 



ACF_infoJnd 



ACF_info_rsp 



RLCJNFO_ACK 



( {info-count, 

ci-data, 

die-attributes}) 



MT_Assoeiated_to_AP 



T info_ack 



Table 25: RLC-INFO 



RLC-INFO-ARG : 


= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE, 


info-count 


INFO-COUNT, 


info-type 


INFO-TYPE, 


cl-data 


CL-DATA OPTIONAL, 


dic-attributes 


DLC-ATTRIBUTES OPTIONAL } 



Table 26: RLC-INFO-ACK 



RLC-INFO-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE, 

info-count INFO-COUNT, 

cl-data CL-DATA OPTIONAL, 

dIc-attributes DLC-ATTRIBUTES OPTIONAL } 



5.1 .2 Key Management 
5.1.2.1 General 

Key management consists of key generation and refresh as well as handling of keys to various BRAN external entities 
such as key databases. Only those parts of key management that are necessary for interoperability are included in the 
Hiperlan/2 standard. 
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The keys used for authentication are long-term keys. They shall be available at both MT and AP side before 
authentication (if desired) can take place. How to generate, configure, store or fetch the keys (and public key 
certificates) are outside the scope of HIPERLAN/2 standards. 

Keys are needed for unicast and broadcast/multicast encryption. Both types of keys are short-term and can be refreshed. 
The interval for key refresh is regulated by the local security policy. 

The unicast key SSK (Session Secret Key) is a secret key known only to one MT and its connected AP. As the name 
("session") implies it is valid for a limited period. 

Unicast key generation during initial association is described in subclause 5.1.2.5. 

5.1 .2.2 Unicast Key Refresh (OAP) 

SSK should be refreshed regularly to maintain security. When the key lifetime expires, a new SSK key should replace 
the old one. It is preferable to start the key refresh process before the current key expires. 

When the current SSK is going to expire, the AP should send a random value nonce encrypted with the current SSK, 
that is, SSK(nonce), to the MT. Upon receiving, the MT shall decrypt nonce, calculate the new encryption key SSK' and 
when ready, send a hash value of it MD5(nonce) back to the AP as confirmation. The AP shall verify the hash value to 
make certain that nonce has been correctly received by the MT. Both parties shall now start to use SSK'. Both the MT 
and AP shall compute the SSK' as follows: 

KeyMat = Kl I K2 I K3 I ... 
Where 

Kl = HMAC-MD5(g''*' mod n, nonce) 

K2 = HMAC-MD5(g''^ mod n, Kl I nonce) 

K3 = HMAC-MD5(g''^ mod n, K2 I nonce) 
etc. 
Kl contains the most significant bits of the concatenated KeyMat. 

g"^ mod n is the Diffie-Hellman secret obtained during the last execution of the encryption startup procedure. 
The SSK' shall be derived from the KeyMat as described in subclause 5.1.2.5. 
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Diagram 24: Unicast Key Refresh 



MSC Unicast_Key_Refresh 
















MT_ENV 




MT_RLC 




AP_RLC 




AP_ENV 
































/ \ 
< MT_Associated_to_AP '} 

\ / 








ACF_unicast_key_refresh_ind 


RLC_UNICAST_KEY_REFRESH 


ACF_unicast_key_refresh_req 








({mac-id, 
nonce}) 




({nonce}) 
RLC_UNICAST_KEY_REFRESH_A( 


({mac-id, 
nonce}) 

AC F_u n icas t_key_ref resln_rsp 


T_unicast_key_refresli 
ACF_unicast_key_refresh_cnf 


({mac-id, 
md5-on-nonce}) 


({md5-on-nonce} ) 






({mac- id, 
md5-on-nonce}) 








/ \ 
/ MT_Associated_to_AP \ 

\ / 



















Table 27: RLC-UNICAST-KEY-REFRESH 



RLC-UNICAST-KEY-REFRESH-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE, 
nonce NONCE } 



Table 28: RLC-UNICAST-KEY-REFRESH-ACK 



RLC-UNICAST-KEY-REFRESH-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE, 

md5-on-nonce MD5-QN-N0NCE } 



5.1 .2.3 Common keys (OAP/OMT) 
5.1.2.3.1 General 

Common keys are used for encryption of multicast and broadcast user data and are used if encryption is chosen in the 
join procedure. Common keys are also used for the encryption of DiL data. Every common key shall be associated with 
an identifier (key-id). 

The AP shall generate and distribute common keys to MTs. One common key may be used for broadcast only, for one 
multicast group only, for more than one multicast group, or for both broadcast and multicast. If the encryption is chosen 
to be used, the AP shall encrypt multicast/user broadcast data with a common key using a chosen algorithm. It is 
assumed that all MTs in the cell support this encryption algorithm. The decision for the algorithm shall be made by the 
AP. 

Common keys shall be generated by APs on a stand-alone basis. A random number generator should be used to produce 
the KeyMat. 
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NOTE: The random number generator should produce random numbers with good characteristics to get a secure 
system. Implementers should strive for good random properties for the random generator output (see 
Bibliography, "Applied cryptography Second Edition" and "Randomness Recommendations for Security" 
for further information about this subject). 

A common key shall be derived from the KeyMat as described in 5.1.2.5. 

5.1 .2.3.2 DM Common Key Distribution (OAP/OMT) 

The DM Common Key Distribution is introduced in 5.1.1.7. 

5.1 .2.3.3 Common Key Refresh (GAP) 

When it is time to refresh a common key, the AP should generate a new common key as described in 

subclause 5.1 .2.3. 1 . The AP shall send the new key to every related MT encrypted with the respective unicast key. The 

key identifier shall tell MTs which common key is to be updated. Each MT shall decrypt and send back a hash value as 

confirmation. 

After receiving confirmation from all the related MTs in the cell, the AP shall send out a broadcast message to activate 
the common key. If the key identifier contained in the activation message is unknown to the MT, the MT shall ignore the 
message. Otherwise the MT shall associate the newly received common key to this key identifier. From now on the new 
common key shall be used. 
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Diagram 25: Common Key Refresh 



MSC Common_Key_Refresh 



MT ENV 



MT_RLC 



AP_RLC 



AP ENV 



(ACF 



ACF_commonkey_refreshind 



COMMON-KEY-REFRESH-ARG) 



ACF_common_key_refreshrsp 



(ACF-CO 



MMON-KEY-REFRESH-ACK-ARG 



AC Fco m mo n_key_act ivate_ind 



( ACF-CO MMON-KEY-ACTIVATE-ARG) 



MT_Associated_to_AP 



RLC_COMMON_KEY_REFRESH 



( {encr-info, 
key-id, 
common-key}) 



RLC COMMON KEY REFRESH ACK 



({encr-info, 
md5-on-key}) 



RLC COMMON KEY ACTIVATE 



({key-id}) 



ACF_common_key_refresln_req 



( ACF-COMMON-KEY-REFRESH-ARG) 
Too m mo n_key_refresh 



CommonKey is tine new | 
key for the already used 
KeyJD, i.e., it will replace 
the old key which is currently 
associated to that KeyJD 



ACF_common_key_refreshcnf 



(ACF-COMMON-KEY-REFRESH-ACK-AR0 
ACF_common_key_activate_req 



( ACF-COMMON-KEY-ACTIVATE-ARG) 



This message is sent in RBCH to 
activate the new key, i.e., 
from now on the new key 
is associated to the Key_ID. 
Special care must be taken to 
ensure the reception of this 
signal. 



MT_Associated_to_AP 



Table 29: RLC-COMMON-KEY-REFRESH 



RLC-COMMON-KEY-REFRESH-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE, 


encr-info 


ENCR-INFO, 


key-id 


KEY-ID, 


common-l<ey 


COMMON-KEY | 



£75/ 



47 ETSI TS 101 761-2 VI. 1.1 (2000-04) 

Table 30: RLC-COMMON-KEY-REFRESH-ACK 



RLC-COMMON-KEY-REFRESH-ACK-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE, 

encr-info ENCR-INFO, 

md5-on-key MD5-0N-KEY } 



Table 31 : RLC-COMMON-KEY-ACTIVATE 



RLC-COMMON-KEY-ACTIVATE-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-SCH-PDU-TYPE, 
key-id KEY-ID } 



5.1 .2.4 RBCH-Seed Transfer 

Seed shall be used to support IV generation that is needed for encryption. A seed shall be transferred to the MT in the 
RBCH. The following rules apply to handling of the seed transfer: 

1 . The seed shall be sent repeatedly in each Nth frame when the AP supports encryption. The AP may send the seed 
also whenever needed. 

2. The seed transmission shall be synchronized with the used sleep cycles. 

3. A MT that intends to use encryption shall from the start of the RLC_LINK_CAPABITY message (in both 
Association and NW Handover) try to update its internal seed generator. The AP shall provide at least one seed 
value during the Link Capability/HO Link Capability and Encryption Start-up/Token-Signalling procedures during 
Association and Network Handover. The value for the repetition of seed (N) isvendor specific. 

4. The MT shall receive a seed before starting the procedure that follows encryption start up/Token Signalling. 

NOTE: Data will be lost during N frames if a residual error occurs at reception of the seed in the MT. Care should 
therefore be taken to avoid too high N values. 

5.1.2.5 Encryption key calculations 
5.1.2.5.1 Diffie-Hellman Key Exchange 

A Diffie-Hellman Key Exchange [24] shall be carried out in the association phase to generate the unicast encryption 
key. The two parameters required by the Diffie-Hellman (DH) key exchange, a base generator g and a big prime number 
n, shall be pre-configured to the following value in both MT and AP: 

g = 2 

n = 2^^768 - 2^^704 - 1 + 2'^64* { [2] + 149686} (Oakley group 1, see [24]) 

The hexadecimal value of n is: 

FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 

020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 

4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF 

During the Diffie-Hellman Key Exchange, both MT and AP shall generate a random number as their DH private value, 
say MT has x and AP has y. The MT shall calculate its DH public value MtDhPublicValue = g^ mod n and send it to the 
AP. Likewise the AP shall calculate ApDhPublicValue = g^ mod n and send it to the MT. After that both the MT and AP 
shall calculate the keying material as described in the following subclauses. 

NOTE: The Diffie-Hellman key exchange relies on random numbers with good characteristics to get a secure 

system. Implementers should strive for good random properties for the random number generator output 
(see Bibliography, "Applied cryptography Second Edition" and "Randomness Recommendations for 
Security" for further information about this subject). 

The MT shall calculate the relevant encryption key before sending the first message after the Encryption Startup 
procedure. 
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5.1 .2.5.2 DES Key Calculation 

For DES encryption, 

KeyMat = HMAC-MD5(g''^ mod n, 0x00), (HMAC-MD5 is explained in subclause 5.1.2.6.1) 

in which the first (most significant) 8 octets shall be taken out as the session key SSK. The least significant bit in each 
octet of SSK shall be the parity bit, and it shall be set according to [2] . 

The SSK shall be checked against all weak and semi-weak keys (keys that have a dual) [2] known to the DES algorithm. 
If SSK is weak or semi -weak, a new KeyMat shall be generated by increasing the second parameter in the HMAC-MD5 
function, that is, compute 

KeyMat = HMAC-MD5(g''^ mod n. Ox 01) 
KeyMat = HMAC-MD5(g''^ mod n. Ox 02) 

until a non-weak and non-semi-weak key is obtained. 

5.1 .2.5.3 Calculation of Triple DES keys (OAP/OMT) 

The key used for the first DES encryption module (that receives the IV) is called keyl, the key for the second DES 
decryption module is called key2 and the key for the last DES encryption module is called key3. 

KeyMat = Kll K2 
Where 

Kl = HMAC-MD5(g''>' mod n. Ox 00) 

K2 = HMAC-MD5(g''^ mod n, Kl I Ox 00), 
Kl contains the most significant bits of the concatenated KeyMat. 

The first (most significant) 8 octets of KeyMat shall be taken as keyl, the next 8 octets shall be taken as key 2 and the 
next 8 octets as key3. The least significant bit in each octet of the keys shall be the parity bit. The parity bits shall be 
calculated according to [2]. 

For the three keys (keyl, key2 and key3), the following checks shall be performed 

• Check each of them against all weak and semi-weak keys known to the DES algorithm [2] 

• Check that all three keys are different. 

If any of the checks above fails a new KeyMat is generated by increasing the second parameter in the HMAC-MD5 
function, that is, compute 

KeyMat = Kll K2 
Where 

Kl = HMAC-MD5(g''^ mod n. Ox 01) 

K2 = HMAC-MD5(g''*' mod n, Kl I Ox 01) 

KeyMat = Kl I K2 
Where 

Kl = HMAC-MD5(g''^ mod n. Ox 02) 

K2 = HMAC-MD5(g''*' mod n, Kl I Ox 02) 

until non-weak, non-semi-weak and different keys are obtained. 

5.1 .2.5.4 Unicast Key Generation at Network Handover (Mandatory if Handover supported) 

The network handover procedure is described in 5.2.1.3. 
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A new SSK for unicast encryption shall be generated at the end of each successful network handover. Both the MT and 
new AP shall calculate a new KeyMat as follows: 

KeyMat = Kll K2 I K3 I ... 
Where 

Kl = HMAC-MD5(g''^ mod n, nonce) 

K2 = HMAC-MD5(g'''' mod n, Kl I nonce) 

K3 = HMAC-MD5(g''^ mod n, K2 I nonce) 
etc. 
Kl contains the most significant bits of the concatenated KeyMat. 

in which, 

g"^ mod n is the earlier established Diffie-Hellman secret, 
nonce is a random value contained in the handover token. 

The new SSK shall be derived from the KeyMat as described in subclause 5.1.2.5. 

Nonce+1, nonce+2,..., shall be used as the second parameter in the HMAC-MD5 calculation if the first key check fails. 
The value is increased by one until the key check procedure gives a successful result. 

5.1.2.6 Authentication functions 

5.1.2.6.1 Algorithms 

MD5 and HMAC are mandatory to implement, since DES encryption is mandatory to implement, whereas RSA is 
optional to implement. All are optional to use. 

MD5 (Message Digest 5), [6] is a one-way hash algorithm developed by RSA Data Security, Inc. It can be used to hash 
an arbitrary-length byte string into a 128 -bit value. 

HMAC (Message Authentication with keyed Hashing) [7] is a mechanism for message authentication using keyed hash 
algorithms. HMAC-MD5 works as follows: 

HMAC-MD5(k, m) = MD5((k XOR opad) I MD5((k XOR ipad) I m)) 

in which k is the secret key, m is the message, ipad (inner padding) is 0x36 repeated 64 times, opad (outer padding) is 
Ox5c repeated 64 times, 'XOR' is exclusive OR, and T is concatenation. 

RSA (see Bibliography, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems, Communications 
of the ACM") is a public -key algorithm. It can be used for digital signatures. Assume a user A has a pair of RSA keys, a 
private key PrivKeyA and a public key PubKeyA- A can digitally sign a message m by first hashing m and then encrypting 
the hash value with PrivKeyA- Anyone can verify A's signature by decrypting it with PubKeyA and then checking the hash 
value. 

5.1.2.6.2 Authentication protocols 

In the association phase, if authentication is chosen, it shall be performed after the Diffie-Hellman key exchange (see 
Encryption Startup MSC). 

NOTE: To detect man-in-the-middle attacks that, over the radio link, are difficult but yet potentially possible to 
launch with DH exchange, the DH public values exchanged are linked to the authentication procedure. 
Proposed and selected encryption and authentication alternatives are also included to combat attacks 
aiming for a lower security level than requested. 

The authentication protocol shall be negotiated between the AP and the MT. Five alternatives are specified: 

1 . Pre-shared key based 

2. RSA512(OAP/OMT) 

3. RSA768 (OAP/OMT) 

4. RSA 1024 (OAP/OMT) 

5. No authentication 
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If authentication is chosen, either pre-shared key based or pubHc key (RSA) based, a challenge-response scheme shall 
fulfil the task. The challenge should be a random number sent by the verifier to the claimant. The claimant shall 
calculate a response using a function with the challenge as input. The function to use depends on which alternative (1 or 
2-4) is chosen. 

If the MT authentication succeeds, the MT is allowed to access the network and the association procedure should 
continue. Otherwise the MT shall be rejected and the DLC connection between the MT and AP shall be terminated. The 
MT may also terminate the access attempt if the AP authentication fails. 

NOTE: The challenge-response scheme needs a random number with good characteristics to get a secure system. 
Implementers should strive for good random properties for the random number generator output (see 
Bibliography for further discussion on this subject). 

5.1 .2.6.3 Pre-shared key based authentication 

In this alternative a party is authenticated if it has knowledge of the pre-shared key. In this case, the key shall be 
generated and distributed to the communicating parties in advance. 

NOTE: Because of key management overhead, this solution is primarily applicable to business and residential 
environment with a limited number of users and administrative domains. 

The response shall be calculated as follows when pre-shared keys are used: 

mt-response = HMAC-MD5(PresharedKey, MtAuthenticationString) 

MtAuthenticationString = challenge_to_mt I mt_dh_public_value I ap_dh_public_value I authentication_encryption_list I 

auth_encr_selected. 

ap-response = HMAC-MD5(PresharedKey, APAuthenticationString). 

APAuthenticationString = challenge_to_ap I mt_dh_public_value I ap_dh_public_value I authentication_encryption_list I 

auth_encr_selected 

MtAuthenticationString and APAuthenticationString are concatenations of a few items. These items shall be 
concatenated in the same order (from left to right) as shown above. Each item shall be appended with the most 
significant bit first. 

challenge-to-mt: the challenge sent by AP to MT, 128 bit long 

challenge-to-ap: the challenge sent by MT to AP, 128 bit long 

mt-dh-public-value: MT's Diffie-Hellman public value, 768 bit long 

ap-dh-public-value: AP's Diffie-Hellman public value, 768 bit long 

authentication- encryption-list: the list of authentication-encryption alternatives proposed by MT during the link 
capability phase, n*8 bit long (n is the number of authentication-encryption alternatives in the list) 

auth-encr-selected: the authentication-encryption alternative selected by AP during the link capability phase, 8 bit long 

The length of the pre-shared key should be at least 128 bits, see RFC 2104 [23]. 

5.1 .2.6.4 Public key based authentication (OAP/OMT) 

To use public -key cryptography, the most important thing is to assure the authentic binding between a public key and its 
owner. A public -key certificate signed by some trusted authority is an effective means to distribute public keys securely. 
A public key infrastructure (PKI) provides mechanisms to issue, fetch, verify or revoke public-key certificates. 

In this alternative a party is authenticated if it has the ability to correctly generate a digital signature. The signature and 
verification calculations shall be done as defined in [PKCS#1] using MD5 as hash algorithm. The response shall be 
calculated as follows when a public key solution is used: 

mt-response = RS ASS A-PKCS-V l_5-SIGN(MtPrivKey,MtAuthenticationString) 

ap-response = RS ASS A-PKCS-V l_5-SIGN(ApPrivateKey,ApAuthenticationString) 
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MtAuthenticationString and ApAuthenticationString are the same as described in 5.1.2.6.3. 
Three public key lengths are supported; 512, 768 and 1024 bits. 

5.1.3 Disassociation 

Disassociation is for releasing MT's association to a particular AP. There are two types of disassociation, 1) explicit and 
2) implicit. 

1. In the explicit disassociation either the MT or the AP initiates the disassociation. The initiating peer (either MT 
or AP) shall send the RLC_DlSASSOClAT10N message and the other peer shall respond with 
RLC_D1SASS0C1AT10N_ACK message. After sending the RLC_DISASSOClATION message or when 
receiving the same from MT, the AP should release the resources for the MT. 

2. The Implicit disassociation should take place when the MT and the AP have lost the ability to communicate via 
the radio interface. In this case, the MT_Alive process shall notice that the MT or/and AP can not be reached and 
the resources for the MT should be released by the AP. 

NOTE: In the MT Initiated Disassociation, the MT may not wait for the RLC_DISASSOCIATION_ACK. 

Diagram 26: MT Initiated Disassociation 



MSC Mr init disassociation 



MACJD_ASSICNED 



ACFdisassoc iationreq 



(ACF-DISASSOCIATION-ARG ) 



Tdisassoc iai iaimt 



)f- 



ACF_disasa3 ciatio n_cnf 



( ACF-DISASSOCIATION-ACK-ARG) 



Ta^minate al 1 
DUCs 



R1jC_DISASSOCIATION 



( { disassociation-cause, 
mac-id } ) 



ACF_disassociation_irKl 



(ACF-DISASSOCIATION-ARG) 

ACF_disass3 cial b n_rsp 



RLC_DISASSOCIATION_ACK 



( ACF-DISASSOCIATION-ACK-ARG) 



( (mac -id}) 



I This MT initiated 

I disassociatbn procedure 

! is optional 



Terminate all 
DUCs 



MT_DISASSOCIATED_FROM_AP 



Table 32: RLC-DISASSOCIATION 



RLC-DISASSOCIATION-ARG ::= SEQUENCE { 



ric-pdu-type RLC-SCH-PDU-TYPE, 
disassociation-cause DISASSOCIATION-CAUSE, 
mac-id MAC-ID } 



Table 33: RLC-DISASSOCIATION-ACK 



RLC-DISASSOCIATION-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type 
mac-id 



RLC-SCH-PDU-TYPE, 
MAC-ID - (if Uplink) -} 
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Diagram 27: AP Initiated Disassociation 



MSC AP_init_disassociation 










MT_BMV MT_RLC AP_RljC 


AP_ENV 














/ MAC_ID_ASSIGNED \ 








ACF_di.sassociation_ind 


RLC_DISASSOCIAT[ON 


ACF_disasso ciatb n_req 








(ACF-DISASSOCIATION-ARG) 




( {disassodation-cause}) 
R IjC_DISA SS OCI ATION_ACK 




7 


T_di sassociation_ap 


{ ACF-DISASSOCIATION-ARG) 

ACF_disassoc iation_rsp 


(ACF-DISASSOCIATION-ACK-ARG ) 


({mac -id}) 


ACF_disaffioc iation_cnf 










(ACF-DISASSOCIATION-ACK-ARG 










Termimteall 
DUCs 






Terminate all 
DUCs 






1 






1 






/ MT_DISASSOCIATED_FROM_AP \ 











5.1.4 Multicast (OAP/OMT) 



In order to join multicast groups the MT shall first have to be associated to the AP as an individual and the MT should 
also have made connection set-ups for unicast traffic. If individual connections are not set up before the group join 
attempt, the AP cannot use the n x unicast method. 

There shall be two ways of implementing multicast; using multicast MAC ID and transmitting the information once to a 
multicast group over the air and n times unicast where the information is transmitted individuallyto each member of the 
group. 

The multicast MAC ID method shall use multicast MAC IDs from the range 224 to 255. 

The MT shall initialize the group joining by sending the RLC_GROUP_JOIN message to the AP. The MT shall use a 
higher layer address as the group identifier in the request. The MT shall also propose the encryption algorithms it wants 
to use. 

The AP shall acknowledge the request by sending MAC IDs and the selected encryption algorithm and keys for each 
group. Each RLC_GROUP_JOIN_ACK message shall have exactly one encryption algorithm, one common key and one 
key id and all HL addresses and all MAC -Ids having those security parameters. Other groups with other security 
parameters shall use other RLC_GROUP_JOIN_ACK messages. 

The MAC ID shall be either a Multicast MAC ID from the permitted range or the individual MAC ID that the MT is 
already using. If it is the MAC ID that the MT is already using, then the multicast traffic shall use one of the DLCC-IDs 
that the MT is already using. If it is a multicast MAC ID, then the DLCC-ID 63 shall be used. 

How the AP decides on the method, multicast or n x unicast, is not a part of the present document. 
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Diagram 28: Multicast Group Join 



MSC MulticastGroupJoin 

MT ENV MT RLC 



AP RLC 



AP ENV 



MT_associated_or_GroupJoined 



ACF_ groupJ oin_ req _ 

(ACF-GROUP-JOIN-ARG) 

T_groupJoin 



_RLG_GROUP_JOIN 

; {cl-data, 
encryption-aigorithm-proposal} 



ACF_groupJoin_ind 



(ACF-GROUP-JOIN-ARG) 



loop <1, 6> multicastJoin_ack 



Groupjoined 



Table 34: RLC-GROUP-JOIN 



RLC-GROUP-JOIN-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE, 

cl-data CL-DATA, 

encryption-algorithm-proposal ENCRYPTION-ALGORITHM-PROPOSAL ; 



Diagram 29: IVIulticast Group Join Ack 



MSC multicastJoin_ack 

MT_ENV I I MT_RLC 



ACF_group_join_onf 



( ACF-GROUP-JOIN-ACK-ARG 



AP RLC 



AP ENV 



ACFgroupJoinrsp 



( ACF-GROUP-JOIN-ACK-ARG 
RLC_GROUP_JOIN_ACK 



( {more-joins, 

cl-data, 

mac -ids, 

encryption-aigorithm -selected, 

key- id, 

common-key}) 



£75/ 



54 



ETSI TS 101 761-2 VI. 1.1 (2000-04) 



Table 35: RLC-GROUP-JOIN-ACK 



RLC-GROUP-JOIN-ACK-ARG::= 


SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE, 


more-joins 


MORE-JOINS, 


mac-id-and-cl-data-list 


MAC-ID-AND-CL-DATA-LIST, 


encryption-algorithm-selected 


ENCR-INFO, 


key-id 


KEY-ID, 


common-l<ey 


COMMON-KEY} 



Table 36: RLC-GROUP-JOIN-NACK 



RLC-GROUP-JOIN-NACK-ARG::= SEQUENCE { 



rIc-pdu-type RLC-PduTYPE, 

more-joins MORE-JOINS, 

mac-id-and-cl-data-list MAC-ID-AND-CL-DATA-LIST 1 



When a MT leaves a group, it shall send a group-leave-request to the AP. The MT shall use the higher layer address as 
the group identifier. The AP shall acknowledge the request positively and again use the higher layer address as an 
identifier. 

Diagram 30: Multicast Group Leave 



MSG MulticastGroupLeave 

MT ENV I I MT_RLC 



AP_RLC 



AP ENV 



Groupjoined 



ACF_groupJeave_req 



(ACF-GROUP-LEAVE-ARG^ 
T_group_leave 



RLC GROUP LEAVE 



({cl-data}) 



RLC GROUP LEAVE ACHj 



({cl-data}) 



ACF_group_leave_cnf 



( /,CF-GROUP-LEAVE-AGK-ARG) 



ACF_groupJeave_ind 



(ACF-GROUP-LEAVE-ARG ) 
AGF_groupJeave_rsp 




DisengagedJrom_these_groups_StilLcommunicating_unicast_and_other_groups_if_any 



Table 37: RLC-GROUP-LEAVE 



RLC-GROUP-LEAVE-ARG::=SEQUENCE { 



rIc-pdu-type 
cl-data 



RLC-LCH-PDU-TYPE, 
CL-DATA } 



Table 38: RLC-GROUP-LEAVE-ACK 



RLC-GROUP-LEAVE-ACK-ARG::=SEQUENCE{ 



rIc-pdu-type 
cl-data 



RLC-LCH-PDU-TYPE, 
CL-DATA } 
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5.1 .5 CL Broadcast (OAP/OMT, depends on CL) 

In order to join CL (user) broadcast groups the MT shall be first associated to the AP as an individual. 

The MT shall initialize the CL broadcast group joining by sending the RLC_CL_BROADCAST_JOIN message to the 
AP. The MT shall use a higher layer address as the broadcast group identifier in the request. The MT shall also propose 
the encryption algorithms it wants to use. 

The AP shall acknowledge the request by sending MAC IDs, HL-addresses, the selected encryption algorithm and keys 
for each group. 

The broadcast MAC ID can be any free MAC ID except the one used for RBCH signalling (MAC ID=0) and the 
multicast MAC IDs from the range 224 to 255. The DLCC-ID value 63 shall be used for all broadcast traffic. The 
MAC-ID selected by the AP for broadcast tranmission shall not be the one that is already being used for unicast 
transmission. 

The UBCH [5] shall be used for CL broadcast. 

Diagram 31 : CL Broadcast Group Join 



MSC CLBroadcastJoin 

MT ENV 



MT RLC 



AP RLC 



AP ENV 



ASSOCIATED 



ACFcLbroadcastJoinreq 



(ACF-CL-BROADCAST-JOIN-ARG )_ 



TcLbroadcastJoin 



RLC_CL_BROADCAST_JOIN 

(cl-data, 
encryption-algorithm-proposal ) 



ACFcLbroadcastJoinJnd 



(ACF-CL-BROADCAST-JOIN-ARG ) 
ACFcLbroadcastJoin rsp 



RLC_CL_BROADCAST_JOIN_ACK 



ACFcLbroadcastJoincnf 



ACF-CL-BROADCAST-JOIN-ACK-ARG) 



( more-joins 

cl-data, 

window-size, 

mac-ids, 

encryption -algorithm -selected, 

key-id, 

common-key, 

error-corr-mode) 



ASSOCIATED_CL_BROADCAST_JOINED 



( ACF-CL-BROADCAST-JOIN-ACK-ARG 



Table 39: RLC-CL-BROADCAST-JOIN 



RLC-CL-BROADCAST-JOIN-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE, 

cl-data CL-DATA, 

encryption-algorithm-proposal ENCRYPTION-ALGORITHM-PROPOSAL } 
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Table 40: RLC-CL-BROADCAST-JOIN-ACK 



RLC-CL-BROADCAST-JOIN-ACK-ARG::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE, 


more-joins 


MORE-JOINS, 


window-size 


BROAD-WINDOW, 


mac-id-and-cl-data-list 


MAC-ID-AND-CL-DATA-LIST, 


encryption-algorithm-selected 


ENCR-INFO, 


key-id 


KEY-ID, 


common-l<ey 


COMMON-KEY, 


error-corr-mode 


ERROR-CORR-MODE } 



When a MT leaves a group, it shall send a group-leave-request to the AP. The MT shall use the higher layer address as 
the group identifier. The AP shall acknowledge the request positively and again use the higher layer address as an 
identifier. 

Diagram 32: CL Broadcast Leave 



MSC CLBroadcastLeave 



MT ENV 



WIT RLC 



AP RLC 



AP ENV 



ASSOCIATED CL BROADCAST JOINED 





ACF_cLbroadcast_leave_req 


RLC_CL_BROADCAST_LEAVE 


ACF_cLbroadcastJeave_ind 




(ACF 


-CL-BROADCAST-JOIN-ARG ) 






> 
T_cl_broadcast_leave 

ACF_cl_broaclcast_leave_ 


/ 


(cl-data) 

( 
.C_CL_BROADCAST_LEAVE_ACK 






R 

/ 






(ACF-CL-BROADCAST-JOIN-AR 
ACF_cLbroadcastJeave_rsp 


G) 




ACF-CL-BROADCAST-JOIN-ACK 


-ARG 




(cl-data) 






cnf 




(AC 


■-CL-BROADCAST-JOIN-ACK-ARG) 





ASSOCIATED 



Table 41 : RLC-CL-BROADCAST-LEAVE 



RLC-CL-BROADCAST-LEAVE-ARG ::= SEQUENCE { 



rIc-pdu-type 
cl-data 



RLC-LCH-PDU-TYPE, 
CL-DATA } 



Table 42: RLC-CL-BROADCAST-LEAVE-ACK 



RLC-CL-BROADCAST-LEAVE-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type 
cl-data 



RLC-LCH-PDU-TYPE, 
CL-DATA } 
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5.1.6 Association Rejection 

The rejection of the Association procedure shall follow the next three rules: 

1 . The information in RBCH Association does not fit with what is expected by the MT. The MT shall not continue the 
Association procedure. 

2. If the AP does not accept the RLC_MAC_ID_ASSIGN message, the AP shall respond with the 
RLC_MAC_ID_ASSIGN_NACK message. 

3. After the MT has got a MAC ID, the rejecting shall be done by sending RLC_DISASSOCIATION message. Both 
the MT and AP shall use this message for this purpose. The RLC_DISASSOCIATION message shall be used for 
every type of explicit disassociation during all states of the system, not only during the association phase. 

NOTE: Because of varying radio link conditions, the Disassociation may happen implicitly, see 5.1.3. 

5.2 Services supporting RRC (Radio Resource Control) 
5.2.1 Handover (OAP/OIVIT) 

Depending on the MT handover decision three types of handover can be performed: 

• Sector Handover (Inter-Sector); 

• Radio Handover (Inter- APT/Intra-AP Handover); 

• Network Handover (Inter- AP/Intra-Network Handover). 

A radio cell shall be controlled by one APC, whereby APCs may support several transceivers (APT) and, hence, serve 
several radio cells [5]. 

NOTE 1 : The distinction between APC and APT is only relevant for radio handover, where the controlling RLC 

instance may remain the same, while the MAC instance changes. Therefore, for ease of description, in all 
sub-sections of this subclause, except 5.2.1.2, this distinction is not referred explicitly. 

NOTE 2: When initiating a handover to an adjacent radio cell, the MT may not know if it initiates a radio or 
network handover. Therefore, a handover supporting MT should support radio as well as network 
handover procedures. 

NOTE 3: Prior to handover execution the MTs should gather relevant measurements on the frequency used by the 
current AP as well as on the frequencies used by candidate APs for a handover. In order to measure 
neighbouring APs, the MT may use MT Absence. 

NOTE 4: The reason to perform any kind of handover is out the scope of the present document. 

5.2.1 .1 Sector Handover (OAP) 

Sector antennas are optional for APs. If the AP uses sectors, the AP shall support Sector Handover as shown in 
(Diagram 1). 

During the Sector Handover only the antenna sector of the AP shall be changed. 



£75/ 



58 



ETSI TS 101 761-2 VI. 1.1 (2000-04) 



Diagram 33: Sector handover 



MSC Sector Handover 

MT ENV 



MT_RLC 



AP_RLC 



AP ENV 



MT_associated_and_communicating_via_sector_old 



RRC_sector_handover_req 



(RRC-SECTOR-HANDOVER-ARG ) 



Tsectorhandoverreq 



RRCsectorhandovercnf 



RLC SECTOR HANDOVER REOUEST 



({sector-id-new, 
mac-id} ) 



If SCiH available in Sectorold, 
otherwise in RCH of Sectornew 



RRCsectorhandoverind 



(RRC-SECTOR-HANDOVER-ARG ) 
RR C_secto r_h and ove rrsp 



RLC_SECTOR_HANDOVER_A((;^'|C-SECTOR-HANDOVER-ACK-ARG) 

send in new sector 



RRC-SECTOR-HANDOVER-ACK-ARG) 

MT_associated_and_communicating_via_sector_new 



Table 43: RLC-SECTOR-HANDOVER-REQUEST 



RLC-SECTOR-HANDOVER-REQUEST-ARG ::= SEQUENCE { 



ric-pdu-type 

sector-id-new 

mac-id 



RLC-SCH-PDU-TYPE, 
SECTOR-ID, 
MAC-ID } 



Table 44: RLC-SECTOR-HANDOVER-ACK 



RLC-SECTOR-HANDOVER-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-SCH-PDU-TYPE ; 



To perform a sector handover, the MT may send a sector handover request via the old sector, if a SCH is still available 
and feasible for this purpose (i.e. SCH is not needed for other purposes and communication in the old sector is still 
possible). If no SCH is available the MT shall send the request in the RCH of the new sector. After sending 
RLC_SECTOR_HANDOVER_REQUEST the MT shall change to the new sector before the next frame starts. The AP 
shall respond with the RLC_SECTOR_HANDOVER_ACK message via the new sector (in DCCH). 

NOTE: No Reset of ARQ parameters shall be made at sector handover. 

5.2.1 .2 Radio (intra-AP) Handover (OAP/OMT) 

Radio Handover is an optional tool for AP implementations with more than one transceiver per AP (see Figure 3). 

The following prerequisite is made in order to get the radio handover in the simple way it is described here. The central 
controller shall have control of both encryption key and seed for all APTs that are controlled by the central controller. 
The key and the seed shall be identical for all APTs controlled by the controller. 

In a multiple transceiver configuration, for each transceiver, a unique AP ID shall be assigned, i. e. multiple AP IDs are 
assigned to one AP. The AP may provide an address mask during association and handover which indicates the address 
range of the AP ID dedicated for transceiver identification. The parameter apt-address-length conveyed in 
RLC_LINK_CAPABILITY_ACK and RLC_HANDOVER_LINK_CAPABILITY_ACK messages shall indicate the 
number of bits assigned for transceiver identification starting from the least significant bit of the AP ID. 
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NOTE 1 : Using this parameter for multiple transceiver APs allows the MT to distinguish between candidate radio 
cells for radio and network handover, respectively, before initiating the handover procedure. 

In case of single transceiver APs the apt-address-length shall be set to zero. 

Values of apt-address-length greater than zero shall be indicated only, when the AP supports radio handover (copy to 
parameter). In a single coverage area using APs with identical net-id the apt-address-length shall be set to the same 
value in all APs. 



NOTE 2: According to the above dependencies, the MT may not know if it initiates a radio or network handover, 
when the corresponding apt-address-length is set to zero, since both handover types are initiated by the 
MT with the same RLC message. 



Radio Handover 



Network Handover 






CL+HL 




CL + HL 






EC 




EC 


MAC 


MAC 


MAC 




PHY 




PHY 


PHY 


PHY 
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APT: Access Point Transceiver 
PC: Access Point Controller 



HL: Higher Layer 



EC 

MAC 



H 



PHY II PHY II PHY 



J 



Figure 3: Informative radio and networl< hiandover scenarios 

NOTE 3: The figure is an example of APT-APC division and does not make any restrictions for implementation. 

NOTE 4: In such a configuration, a radio handover may be performed when an associated MT moves from the 
coverage area of one APT to another, which is served by the same APC. Since the handover execution 
may be performed within the DLC layer, the Higher Layer Protocols (HL) may not be involved. 
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Diagram 34: Radio hiandover overview 



MSC High_Level_Radio_Handover 



1(1) 




Associ ate d_t o_APT_old 



Force Handover 



Radio_Handover 



Associated_to_APT_new , 



If the MT is still synchronized to the current APT, when triggering a handover to another (target) APT, the MT may 
notify the AP via the current APT (RLC_HANDOVER_NOTIFY message), that it will perform a handover to another 
APT. 

NOTE 5: This message is only useful in case of network handover, since the AP is implicitly informed, when the 
MT initiates a radio handover. However, the MT may not be aware of the type of handover it initiates. 

The MT may return within 255 frames from the frame, where the RLC_HANDOVER_NOTIFY message was sent 
(sending frame is number 0). If the MT returns to the current APT it shall notify the AP. In case data waits for 
transmission in the MT, it sends Resource Requests to the AP and, hence, informs it thereby about its presence. In case 
no data has to be transmitted, the MT shall trigger the MT-ALIVE procedure. 
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Diagram 35: Radio hiandover 



MSC Radio Handover 



MT ENV 



MT_RLC 



AP_RLC 



AP ENV 



Associated to APT old 



opt 



RRC_handover_notify_req 



(RRC-HANDOVER-NOTIFY-AR3 



RLC HANDOVER NOTIFY 



({handover-cause, 
net-id, 
ap-id, 
mac - I d) 



RRG_handover_notlfy_ind 



(RRC-HANDOVER-NOTIFY-ARG 



MTsynchronlsedtoAPTnew 



RRC_forward_handover_req 



(RRG-FORWARD -HAN DOVER 



'^l?ft;JHANDOVER_REQUEST 



Thandoverrequest 



RLC 



RRC_radio_handover_cnf 
RRC-FOR\iVARD-HANDOVER-ACK-ARG ) 



({mac-Id-Old, 
ap-id-old, 
net-id-oid, 
due-established, 
mac-Id 0} ) 



( RRC-FORW/^RD-HANDOVER-ACK-ARG ) 
RADIO HANDOVER COMPLETE 



( {mac-id-oid, 

ap-id -old, 

mac-Id- new, 

cl-id, 

duc-ext-ind, 

cl-conn-attr-length, 

duc-descr-llst}) 

Assoclated_wlth_new_APT_ 
Han dove r_com plot ed_to_new_APT 



RRC forward handover ind 



Different Transceiver 
at the same AP 
(Freq. changed) 



(RRC-FORWARD-HANDOVER-ARG 



Connection and Security Parameter 
and Options are Processed 



Redirect 

Connections 

to MAC_new and 

update DUC_LIST 

RRC_radlo_handover_rsp 



Table 45: RLC-HANDOVER-NOTIFY (OAP/OIVIT) 



RLC-HANDOVER-NOTIFY-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-SCH-PDU-TYPE, 


handover-cause 


HANDOVER-CAUSE, 


mac-id 


MAC-ID, 


ap-id 


AP-ID OPTIONAL, 


net-id 


NET-ID OPTIONAL} 
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Table 46: RLC-HANDOVER-REQUEST 



RLC-HANDOVER-REQUEST-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-SCH-PDU-TYPE, 


mac-id-old 


MAC-ID, -MAC-ID used in old APT 


ap-id-old 


AP-ID, - AP-ID of old APT 


net-id-old 


NET-ID, 


due-established 


DUC-ESTABLISHED } 



Table 47: RLC-RADIO-HANDOVER-COMPLETE 



RLC-RADIO-HANDOVER-COMPLETE-ARG ::= SEQUENCE { 


rIc-pdu-type 


RLC-LCH-PDU-TYPE, 


mac-id-old 


MAC-ID, 


ap-id-old 


AP-ID, 


net-id-old 


NET-ID, 


mac-id-new 


MAC-ID, 


cl-id 


CL-ID, 


duc-ext-ind 


DUC-EXT-IND, 


cl-conn-attr-length 


INTEGER(0..31), 


duc-descr-list 


DUC-DESCR-LIST} 



The MT triggers handover by sending RLC_HANDOVER_REQUEST to the target AP, which shall then select the 
handover procedure (either radio or network handover). 

In case of a radio handover the AP shall respond with RLC_RADIO_HANDOVER_COMPLETE message to approve 
the request. The AP shall use RBCH for sending this message. MT shall update the unicast DUCs according to 
RLC_RADIO_HANDOVER_COMPLETE message before sending any Resource Requests. In this message the AP may 
either confirm the characteristics of the DUCs established in the previous radio cell or modify them. 

If not all DUCs, which the AP intends to maintain after handover, can be indicated in 

RLC_RADIO_HANDOVER_COMPLETE, the AP shall set the duc-ext-ind flag and address the remaining DUCs in 
subsequent DUC Modify. 

DUCs established in a previous radio cell, but addressed neither in RLC_RADIO_HANDOVER_COMPLETE nor in 
subsequent DUC Modify by the AP shall be considered by the MT as released. 

After radio handover AP, i. e. after sending RLC_RADIO_HANDOVER_COMPLETE, and MT, i. e. after receiving 
RLC_RADIO_HANDOVER_COMPLETE, shall trigger the reset actions for the on-going DUCs in acknowledged 
mode (ref. [5]) only, when the DUCs are modified in RLC_RADIO_HANDOVER_COMPLETE or DUC Modify. 

For the rejection of the Radio Handover, see subclause 5.2.1.5. 

5.2.1 .3 Network Handover 

A network handover may be carried out when an associated MT moves from one AP to another AP (Figure 3). Since the 
MT leaves the serving area of an RLC instance, a network handover involves also the CL and higher layers (HL). To 
maintain HL association and connections specific signalling via the fixed network may be needed. 
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Diagram 36: Network Handover procedure 



MSC Network Handover 



To ken_NW_sig nailing 



MT associated with old AP 




Force Handover 



HO Association 



HO_Llnk_Capablllty 



Encryptlon_Startup 



Authentication 



Info Transfer 



Setup_Radlo_Connection_mobile_originated 



Handover_Completlon 



Handover_Complete 



i(i; 



If the MT is still synchronized to the current AP, when triggering a handover to another (target) AP, it may notify the 
current AP by the RLC_HANDOVER_NOTIFY message, that it will perform a handover to another AP. 

The AP shall stop scheduling data to this MT after receiving RLC_HANDOVER_NOTIFY message. 
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The MT may return within 255 frames from the frame, where the RLC_HANDOVER_NOTIFY message was sent 
(sending frame is number 0). If the MT returns to the old AP, the MT shall notify the old AP. In case data waits for 
transmission in the MT, it sends Resource Requests to the AP and, hence, informs the AP thereby about its presence. In 
case no data has to be transmitted, the MT shall trigger the MT Alive procedure. 

Diagram 37: Handover association procedure 



MSC HO_ Association 



AP_new_RIjC 



AP_new_ENV 



MT_ associated_™th_old_AP_ 
Hanctavernecessary 















opt j 


RR C_handover_notif y_req 


R 1jC_H ANDO VER_NOTI FY 
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1 


(RRC-HANDOVER^NOTIFY-ARG ) 


({handover -cause, 
net -id, 
ap-id, 
mac-id j ) 
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(RRC-HA^DOVER-REQUEST-ARG ) 
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( rrc-handover-association-arg; 



Establish the RLC 
Contrd Connection 
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net-id-dd, 
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({mac -id-old, 
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( RRC-HANDOVER-R EQUEST- ARG 



RRC_handovCT_associa tion_rsp 



( RRq-HANDOVER-ASSOCIATION-ARG) 
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tteMT 
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Control ComecSion 
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Table 48: RLC-HANDOVER-ASSOCIATION 



RLC-HANDOVER-ASSOCIATION-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE, 


mac-id-old 


MAC-ID, 


ap-id-old 


AP-ID, 


net-id-old 


NET-ID, 


mac-id-new 


MAC-ID } 



The MT shall trigger handover by sending RLC_HANDOVER_REQUEST to the target AP, which shall then select the 
handover procedure (either radio or network handover). The AP shall respond with the 
RLC_HANDOVER_ASSOCIATION message to approve the request. 

In order to reject the RLC_HANDOVER_REQUEST, the AP shall respond with 

RCL_HANDOVER_REQUEST_NACK message. The AP shall use RBCH for sending these messages. After receiving 
RLC_HANDOVER_ASSOCIATION, the MT shall trigger the Handover (HO) link capability procedure. 
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Diagram 38: Handover link capability procedure 



MSC HO_Link_Capability 
















l\/IT_ 


ENV 




MT_ 


RCP 




AP_ 


RCP 




AP_ 


ENV 






1 1 1 1 

/ MAC_ID_Assigned \ 

\ / 








RRC_link_capability_req 


RLC LINK CAPABILITY 
















(ACF-LINK-CAPABILITY-ARG ) 








({dic-version, 


\ 


/ Thandoverassociatlon 


T_rsp 7 




/ 








ric-version, 












cl-vld-list, 












rss-value, 
support64qam, 


RRCJink_capability_ind 




















freq-band, 


(ACF-LINK-CAPABILITY-ARG ) 










direct-mode-cap, 












cyclic-prefix, 












support-fca. 












support-fsa. 












time-gap-ach-uplink. 












arq-delay-n<. 












arq-delay-tx. 












authentication-encryption-list. 












dm-attrlbutes} ) 








RLC 


4 


NDOVER_LINK_CAPABILITY_ACK 


RRC_ho_llnk_capabllity_rsp 


_ARG) 


( RRC-HO-LINK-CAPABILITY-ACK 


( {dic-verslon-selected. 




RRC ho link capability cnf 


ric-version-selected. 




T_handoverJink_capability_ 


_ack 


^^ 












( RR 


>HO-UNK-CAPABILITY-ACK_ARG ) 


apt-address-length, 

support64qam, 

freq-band, 

direct-mode-cap, 

dm-use-common-key, 

cyclic-prefix, 

support-fca, 

support-fsa, 

arq-delay-rx, 

arq-delay-tx, 

auth-encr-selected, 

start-encryption, 

start-authentication, 

send-NW-Token, 

start-info -transfer, 

keep-connections, 

start-DUC-set-up, 












dm-attrlbutes} ) 










/ Link_Agreed \ 
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Table 49: RLC-HANDOVER-LINK-CAPABILITY-ACK 



RLC-HANDOVER-LINK-CAPABILITY-ACK-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE, 




dic-version-selected 


DLC-VERSION, 




ric-version-selected 


RLC-VERSION, 




rss-value 


RSS-VALUE, 




apt-address-length 


APT-ADDRESS-LENGTH, 




support64QAM 


SUPPORTED64QAM, 




freq-band 


FREQUENCY-BAND, 




direct-mode-cap 


DIRECT-MODE-CAP, 




dm-use-common-key 


DM-USE-CQMMQN-KEY, 




cyclic-prefix 


CYCLIC-PREFIX, 




support-fca 


SUPPQRTED-FCA, 




support-fsa 


SUPPQRTED-FSA, 




sector-ho-cap 


SECTOR-HQ-CAP, 




network-ho-cap 


NETWQRK-HQ-CAP, 




radio-ho-cap 


RADIQ-HO-CAP, 




arq-delay-rx 


ARQ-DELAY, 




arq-delay-tx 


ARQ-DELAY, 




auth-encr-selected 


AUTH-ENCR-INFO, 




start-encryption 


START-ENCRYPTION, 




start-authentication 


START-AUTHENTICATION, 




send-NW-Token 


SEND-NW-TOKEN, 




start-info-transfer 


START-INFO-TRANSFER, 




keep-connections 


KEEP-CONNECTIONS, 




start-DUC-set-up 


START-DUC-SET-UP, 




include-MT-ID 


INCLUDE-MT-ID, 




dm-attributes 


DM-ATTRIBUTES OPTIONAL - (OAP/OMT) - 


-} 



In the link capability procedure the MX shall provide its link capabilities to the AP using RLC_LINK_CAP ABILITY 
message. The AP shall respond with RLC_HANDOVER_LINK_CAPABILITY_ACK. Based on the 
RLC_HANDOVER_LINK_CAPABILITY_ACK a subset of the following procedures shall be executed: Encryption 
Startup, Authentication, Token NW Signalling, Info Transfer, Setup Radio Connection mobile originated. The order of 
the procedures and allowed combinations are presented in Diagram 36. 

Regardless of which procedures are selected, the AP shall complete the entire network handover procedure, by 
transmitting the RLC_HANDOVER_COMPLETE message. In this message the AP may either confirm the 
characteristics of the DUCs established in the previous radio cell or modify them, only in the case DUCs have not 
already been negotiated during the Network Handover, i.e. by Setup Radio Connection mobile originated. 

If not all DUCs, which the AP intends to maintain after handover, can be indicated in 

RLC_HANDOVER_COMPLETE, the AP shall set the duc-ext-ind flag and address the remaining DUCs in subsequent 
DUG Setup. This mechanism may also be used to establish DUCs by the AP. 

DUCs established in a previous radio cell, but addressed neither in RLC_HANDOVER_COMPLETE nor in subsequent 
DUC Setup by the AP shall be considered by the MT as released. 

After network handover AP and MT shall trigger the reset actions for the on-going DUCs in acknowledged mode 
(ref. [5]). 
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Diagram 39: Token network signalling procedure 



MSC Token_NW_signalling 

MT ENV I I MT RLC 



AP new RLC 



AP new ENV 



AP old ENV 



({mt-token-auth-encr} 



Til w_s ig n al li n g_h a nd ove r 



ACF_ 



LinkAgreed 



nwsignallinghandoverreq 

RLC_NW_SIGNALLING_HAND0VEF! 



ACFnwsignallinghandovercnf 



( {mac-id, 

ap-token-auth-encr}) 



({mt-token-auth-encr} ) 



ACF_nw 
RLCt N\N SIGNALLING HANDOVER ACK 



( {ap-token-auth-encr}) 



T_handoverJink_capability_ack 



AGFnwsignallinghandpverind 

ho_info_req 



({mt-token-auth-encr} 



signallinghandoverrsp 



( {mac-id 

ap-token-auth-encr}) 

\ Tnwsignallingh 



({mac-id -oid}) 
hoJnfo_rsp 



{ap-token-auth-encr, 

DHage, 

dh-secre 



andover ack 



t}) 



Associated to new AP 



Table 50: RLC-NW-SIGNALLING-HANDOVER 



RLC-NW-SIGNALLING-HANDOVER-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE, 

mt-token-auth-encr MT-TOKEN-AUTH-ENCR} 



Table 51 : RLC-NW-SIGNALLING-HANDOVER-ACK 



RLC-NW-SIGNALLING-HANDOVER-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE } 

ap-token-auth-encr AP-TQKEN-AUTH-ENCR 



When a MT performs a handover it may send the RLC_NW_SIGNALLING_HANDOVER message, depending on 
send-NW -token in HANDOVER-LINK-CAP ABILITY-ACK. The MT calculates MD5(tokenlauthentication-encryption- 
listlauth-encr-selected) based on the earlier received token, the earlier sent authentication-encryption-list and the 
received auth-encr-selected and sends the result to the AP. 

NOTE: With support of the fixed network, the new AP can contact the old AP directly and verify the continuity. 

The new AP shall do the following for security purposes: 

1 . Contact the old AP, presenting the old MAC ID of the MT and fetching the following information: 

- Token, the same one was sent to the MT by the old AP in the RLC_HO_INFO_DISTRIBUTION message; 

- DHsecret, which equals g"*^ mod n, the result of the last Diffie-Hellman exchange carried out in the encryption 
startup procedure; 

DHAge, how long time the DHsecret has been used. 



£75/ 



68 



ETSI TS 101 761-2 VI. 1.1 (2000-04) 



2. Calculate MD5(tokenlauthentication-encryption-listlauth-encr-selected) and compare the result with the one 
received in RLC_NW_SIGNALLING_HANDOVER. If the two hash values are not equal, reject the MT's 
handover request. 

3. Calculate the new unicast key SSK as described in subclause 5. 1.2.5.4. 

4. Send back the RLC_NW_SIGNALLING_HANDOVER_ACK message, encrypted with the new SSK (if 
encryption is used) . The AP calculates MD5(tokenlauthentication-encryption-listlauth-encr-selected) based on 
the token received from the old AP, earlier received authentication-encryption-list and sent auth-encr-selected 
and sends the result to the MT. 

The MT shall calculate the new SSK (see subclause 5.1.2.5.4) and verify that the received information in the 
RLC_NW_SIGNALLING_HANDOVER_ACK message is the same as used for the calculation of the 
RLC_NW_SIGNALLING_HANDOVER message. 

5.2.1 .4 Token distribution for Network Handover 

The transfer of the token shall bedone while the MT is associated to the current AP. The current AP sends the message 
to the MT. It contains a token encrypted with the unicast key (RLC_HO_INFO_DISTRIBUTION). The MT decrypts 
the token and stores it for later use. It also sends an acknowledgement back to the old AP. 

Diagram 40: Network handover info distribution 



MSCNetwork_Handover_lnfo_Distributi 

MT ENV I MT RLC 



AP RLC 



AP ENV 



MT associated with AP 



ACF_ho_info_distribution_ind 

{tol<en} ) 

ACF_tol<en_distribution_rsp 

{ {mac-id}) 



T_handover_linl<_capabili|y_ 
T_l<ey_exchange_ap 
T authentication ack 



X T_nw_signalling_handovi3r_acl< 
^ACF_ho_info_distribution_req 



RLC HO INFO DISTRIBUTION 



{token} 



RLC HO INFO DISTRIBUTION ACK 



( {mac-id}) 



{token} ) 

T ho info distribution 



ACF ho info distribution cnf 



( {mac-id}) 



ack 



MT associated with AP 



Table 52: RLC-HO-INFO-DISTRIBUTION 



RLC-HO-INFO-DISTRIBUTION-ARG : 


:= SEQUENCE { 


ric-pdu 


-type 


RLC-LCH-PDU-TYPE, 


token 




TOKEN } 
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Table 53: RLC-HO-INFO-DISTRIBUTION-ACK 



RLC-HO-INFO-DISTRIBUTION-ACK-ARG ::= SEQUENCE { 
ric-pdu-type RLC-SCH-PDU-TYPE 

mac-id MAC-ID } 



The Token should be a random value. The Token shall be used for the two following purposes: 

1) to show that the MT is really the one that made a network handover from the old AP to the new AP; 

2) to allow the MT and the new AP to calculate a new SSK based on the Token. 

NOTE: The function needs a random number (see Bibliography, "Applied cryptography Second Edition" and 
"Randomness Recommendations for Security" for further information about this subject). 

NW Handover Info Distribution shall be executed after association and network handover to keep the token up-to-date. 

Diagram 41 : Handover Completion procedure 

MSC Handover_Completion 

MT ENV I I MT RLC AP new RLC AP new ENV 



Associated_with_new_AP 



RLC_NE!TWORK_HANDOVER_COMPLETE 



T_connect_ack X — 
TJink_capability_ack \z 

T_key_exchange_ap \z 

Tauthenticationack \z 

_dm_common_key_distr_ack X — 

T_info_aok X 

T nW_signalling_handoverack X 

RRC network handover cnf 



{mac-id, 

cl-id, 

duc-ext-ind, 

cl-conn-attr-length, 

duc-descr-list}) 



: {cl-id, 

duc-ext-ind, 

cl-conn-attr-lengtin, 

duc-descr-list}) 



RRC_network_handover_rsp 



{mac-id, 

cl-id, 

duc-ext-ind, 

cl-conn-attr-lengtin, 

duc-descr-iist}) 



Tnwhandovercompiete 



Han dove room pie ted_to_new_AP 
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Table 54: RLC-NETWORK-HANDOVER-COMPLETE 



RLC-NETWORK-HANDOVER-COMPLETE-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE, 

cl-id CL-ID, 

duc-ext-ind DUC-EXT-IND, 

cl-conn-attr-length INTEGER(0..31), 

duc-descr-list DUC-DESCR-LIST } 



5.2.1.5 Handover Rejection 

The rejection of the Radio and Network Handover procedures shall follow the next two rules: 

1 . If the AP does not accept the RLC_HANDOVER_REQUEST message, the AP shall respond with the 
RLC_HANDOVER_REQUEST_NACK message. 

2. After the MT has a MAC ID, a possible rejection shall be done by sending RLC_DISASSOCIATION message. 
Both the MT and AP shall use this message for this purpose. 

NOTE: Because of varying radio link conditions, the Disassociation may happen implicitly, see 5.1.3. 



RLC-HANDOVER-REQUEST-NACK-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-SCH-PDU-TYPE, 

mac-id-old MAC-ID, - MAC-ID used in old APT 

ap-id-old AP-ID, - AP-ID of old APT 

net-id-old NET-ID} 



5.2.1 .6 Forced Handover (AP initiated handover) (OAP/OMT) 

APs may initiate HO capable MTs to perform forward handover by using RLC_FORCE_HANDOVER. The AP shall 
make sure that the MT is HO capable. The AP shall stop scheduling data to the MT after sending 
RLC_FORCE_HANDOVER message. 

• If the return-flag value is set to zero, the MT shall respond with RLC_FORCE_HANDOVER_ACK and shall not 
return to the current AP to continue operation with the old association. When the 

RLC_FORCE_HANDOVER_ACK is received by the AP, it shall disassociate the MT without sending the 
RLC_DISASSOCIATION message. 

• If return-flag is set to one, MTs shall respond with RLC_FORCE_HANDOVER_ACK. The MT shall not return to 
operate with old association after 255 frames after the frame the RLC_FORCE_HANDOVER_ACK was received 
by the AP (the receiving frame is number 0). When returning to the old AP, the MT shall continue operation with 
the AP by sending RLC_MT_ALIVE, Resource Request or RLC_HANDOVER_NOTIFY. 
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Diagram 42: Forced handover procedure 



MSC Force_Handover 

MT ENV 



MT RLC 



AP RLC 



AP ENV 



MT_associated_with_olcl_AP_Handover_necessary 



RRC_force_hancloverJnd 



( RRC-FORCE-HANDOVER-ARG) 
RRC_force_handover_rsp 



({mac -id}) 



RLC_FO RCE_HAN DOVER 



( {return-flag, 

force-handover-cause, 

ap-id, 

net-id, 

frequency-index}) 

RLC FORCE HANDOVER ACK 



({mac-id}) 



RRC_force_inandover_req 



RRC-FORCE-HANDOVER-ARG) 



T_force_inandover 



RRC_force_inandover_cnf 



({mac-id}) 



Forced_Handover Initiated 



Table 55: RLC-FORCE-HANDOVER 



RLC-FORCE-HANDOVER-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-SCH-PDU-TYPE, 


return-flag 


RETURN-FLAG 


force-handover-cause 


FORGE-HANDOVER-GAUSE, 


ap-id 


AP-ID 


net-id 


NET-ID 


frequency-index 


FREQUENGY-INDEX} 



Table 56: RLC-FORCE-HANDOVER-ACK 



RLG-FORGE-HANDOVER-AGK-ARG ::= SEQUENGE { 



rIc-pdu-type 
mac-id 



RLG-SGH-PDU-TYPE, 
MAG-ID } 



5.2.2 Dynamic Frequency Selection 

5.2.2.1 Introduction to DFS 

The Dynamic Frequency Selection (DFS) in HL/2 systems shall result in equal usage of available frequencies under the 
consideration of avoiding the interference of other devices using the same spectrum [12]. The interference may arise 
from neighbouring HL/2 networks using the same frequency or non-HL/2 devices in the frequency band. Every AP 
should collect measurement results and choose an operating frequency based on the measurement results. The decision 
may be done independently of other APs. 

5.2.2.2 DFS algorithm 

The DFS algorithm is out of the scope of this specification. 
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5.2.2.3 DFS protocol 

The AP may request any associated MTs to measure and report the measurements. The MT shall perform the 
measurements and after the measurement it shall report the results to the AP. 

A MT may also do self-initiated measurements and request to report the results to the AP. The AP may then poll the MT 
for the result or may ignore the request. The implementation of the RLC_MT_INITIATED_REPORT_REQUEST is 
optional for the MT, but mandatory for the AP. 

Diagram 43: DFS measurements 



MSC DFS Measurements 



1(1) 



Active Mode 



dfs_mt_init_ 
_report_req 



dfs_measurement_ 
_complete_request 




change_frequency 



dfs_ap_absence 



dfs_measurement_ 
_short_request 



dfs_report_complete 




dfs_measurement_ 
_percentiles_request 



dfs_report_percentiles 



5.2.2.4 DFS measurements 

APs and MTs shall be able to perform measurements to support DFS, namely RSS measurements at a given frequency. 
APs and MTs shall be able to decode possible BCH transmissions of other APs at a given frequency. 

The measurements in the AP are out of scope of the specification. 

When the AP is switched on, it shall measure on all frequencies it is permitted to use. 
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5.2.2.4.1 AP Measurement Procedure 

When the AP makes measurements and is not able to transmit, it shall use AP Absence. 

NOTE 1 : AP should disturb sleeping MTs as little as possible. This can be handled by making the measurement 
between MAC broadcast sleep group frames. 

The maximum AP Absence period shall be 15 frames. The AP shall keep its frame cycle during AP Absence. 

NOTE 2: The three shortest sleeping periods for MTs are 2, 4 and 8 frames. The MT that has one of these short 

sleeping periods, may lose 1 to 8 expected BCHs during AP Absence period. The MT can, however, hear 
the AP_ABSENCE message during the MAC broadcast sleep group frame. 

Diagram 44: DFS AP absence procedure 



MSC dfs_ap_absence 



Ml ENV 



MT RLC 



RRC_ap_absence_ind 



{ {mac-id, 

first-mac-frame, 
last-mac-frame} ) 



AP RLC 



AP ENV 



Active IVIode 



RLC AP ABSENCE 



{first-mac-frame, 
last-mac-frame} 



RRC_ap_absence_req 



Active Mode 



( {mac-id, 

first-mac -frame, 
last-mac-frame} 



Table 57: RLC-AP-ABSENCE 



RLC-AP-ABSENCE-ARG ::= SEQUENCE { 



ric-pdu-type 

first-mac-frame 

last-mac-frame 



RLC-SCH-PDU-TYPE, 
FIRST-MAC-FRAME, 
LAST-MAC-FRAME } 



5.2.2.4.2 MT Measurement Procedures 

Three measurement types are defined for a MT: short, percentiles and complete. All of the measurement requests shall 
besent as unicast messages only. 

Short: At the given time and frequency, MT shall scan for BCH. If a BCH is found it shall be decoded and its RSS shall 
be measured. 
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Diagram 45: DFS short measurement request 



RRC 



MSC dfs_measurement_short_request 

MT ENV I MT RCP 



AP RCP 



AP ENV 



Active Mode 



RLC DFS MEASUREMENT SHORT REQUEST 



RRCldfs_measurement_short_request_ind 

^ 

■DFS-ME4SUREMENT-SH0RT-REQUEST-ARG) 



RRC_tllfs_measurement_short_request_req 
( RRC-DFS-MEASL 



UREMENT-SHORT-REQUEST-ARG) 



{frequency-index, 

use-omni-antenna, 

start-of -measurement, 

measurement-window, 

maxim um-age-of-bch-measurement}) 



Active_Mode 



Table 58: RLC-DFS-MEASUREMENT-SHORT-REQUEST 



RLC-DFS-MEASUREMENT-SHORT-REQUEST-ARG ::= SEQUENCE { 



ric-pdu-type 

frequency-index 

use-omni-antenna 

start-of-measurement 

lengtli-of-measurement 



RLC-LCH-PDU-TYPE, 

FREQUENCY-INDEX, 

USE-OMNI-ANTENNA, 

START-OF-MEASUREMENT, 

NUMBER-QF-SAMPLES, 



maximum-age-of-bch-measurement MAXIMUM-AGE-QF-BCH-MEASUREMENT } 



Percentiles: At the given time and frequency, the MT shall collect RSS samples with equal distance 8 )is. 
NOTE: No decoding of BCH is done for percentiles measurement. 
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Diagram 46: DFS percentiles measurement request 



MSC dfs_measurement_percentiles_request 

I MT ENV I I MT RLC I 



AP RLC 



AP ENV 



Active Mode 



RLC_DFS_MEASURE\/IENT_PERCENTILES_REQUEST 



RRC_dfs_measurement_percentiles_request_ind 



RRC-DFS-WEASUREMENT-PERCENTILES-REQUEST-ARG) 



RR C_df s_JTi easure me nt_perce ntiles_req uest_req 

■* 

{ RRC-DFS-MEASURE^^ENT-PERCENTILES-REQUEST-ARG) 



{ {frequency-index, 

use-omni-antenna, 

start-of-measurement, 

measurement-window, 

rss-index-list} 

) 



Active Mode 



Table 59: RLC-DFS-IVIEASUREMENT-PERCENTILES-REQUEST 



RLC-DFS-MEASUREMENT-PERCENTILES-REQUEST-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE, 


frequency-index 


FREQUENCY-INDEX, 


use-omni-antenna 


USE-QMNI-ANTENNA, 


start-of-measurement 


START-QF-MEASUREMENT, 


measurement-window 


MEASUREMENT-WINDQW, 


rss-index-list 


RSS-INDEX-LIST} 



Complete: A combination of the short and percentiles measurements, where at the given time and frequency BCH shall 
be decoded and RSS measurement on the BCH shall be performed and the RSS samples shall be collected. 
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Diagram 47: DFS complete measurement request 



MSC dfs_measurement_complete_request 

I MT ENV I I MT RLC I 



AP RLC 



AP ENV 



Active Mode 



RLC_DFS_MEASU 



R R C_df sLm easure me nt_co mplete_requ est_ind 

« 

RRC-DflS-MEASUREMENT-COMPLETE-REQUEST-ARG) 



RRC_dfq_measurement_complete_request_req 

4 

( RRC-DFS-MEASUFlEMENT-COMPLETE-REQUEST-ARG) 



REMENT_COMPLETE_REQUEST 



{frequency-index, 

use-omni-antenna, 

start-of-measurement, 

measurement-window, 

aximum-age-of-bch-measurement, 

rss-index-list}) 



Active Mode 



Table 60: RLC-DFS-MEASUREMENT-COMPLETE-REQUEST 



RLC-DFS-MEASUREMENT-COMPLETE-REQUEST-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE, 


frequency-index 


FREQUENCY-INDEX, 


use-omni-antenna 


USE-QMNI-ANTENNA, 


start-of-measurement 


START-QF-MEASUREMENT, 


measurement-window 


MEASUREMENT-WINDQW, 


maximum-age-of-bcli-measurement 


MAXIMUM-AGE-QF-BCH-MEASUREMENT, 


rss-index-list 


RSS-INDEX-LIST} 



Each RSS sample measurement shall follow the requirements in [4]. 

The measurement requests described above are sent from AP to MT, but MT may also ask AP to send the request. In 
this case, the AP shall answer MT with an ACK. The ACK shall contain a flag stating whether the AP is going to send a 
request or not. 
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Diagram 48: DFS MT init report request procedure 
(OMT. Optional for thie AP to send a request after receiving the message) 



MSC dfs_mt_init_report_req 



MT ENV 



MT_RLC 



AP RLC 



AP ENV 



Active_Mode 



RRC_dfs_mt_init_report_req 



(RRC-DFS-MT-INIT-REPORT-FJEQUEST-ARG ) 

RLC_DFS_MTJNIT_REPORT_REQUES 



^ 



T_dfs_mt_init_report 



RF!C_dfs_mt_init_report_ack_cnf 



RRC-DFS-MT-INIT-REPORT-ACK-ARG) 



({measurement -type, 
frequency-index, 
adjacent-ch -interfere nee, 
mac-id} 



RLC_DI"S_MT_INIT_REP0RT_REQUEST_AC1^ R=iC-DFS-MT-INIT-REPORT-ACK-ARG) 



{request-in itiaiisation}) 



Active_Mode 



RRC_dfs_mtJnit_report_ind 



(RRC-DFS-MT-INIT -REPORT -REQUE:ST-ARG 
RRG_dfs_mtJnit_report_ack_rsp 



Table 61 : RLC-DFS-MT-INIT-REPORT-REQUEST 



RLC-DFS-MT-INIT-REPORT-REQUEST-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-SCH-PDU-TYPE, 


measurement-type 


MEASUREIVIENT-TYPE, 


frequency-index 


FREQUENCY-INDEX, 


adjacent-ch-interference 


ADJACENT-CH-INTERFERENCE, 


mac-id 


MAC-ID } 



Table 62: RLC-DFS-MT-INIT-REPORT-REQUEST-ACK 



RLC-DFS-MT-INIT-REPQRT-REQUEST-ACK-ARG ::= SEQUENCE { 
rIc-pdu-type RLC-SCH-PDU-TYPE, 
reporting-initialized REPQRTING-INITIALIZED } 



5.2.2.4.2.1 Measurements on other frequencies 

When the AP needs measurements on other frequencies than the one it is currently using, the AP may request one or 
more MTs to do the measurements. In order to do that, the AP shall send one of the three measurement requests. 

The measurement procedure on a currently not used frequency is described below: 

1) The MT shall measure RSSO [4] for the last_own_bch_rss_level from the frame previous to the frame number 
start-of-measurement. 

2) The MT shall start to tune to the specified frequency/from the beginning of the MAC frame that is announced 
with start-of-measurement. NOTE! Tuning time is not included in the measurement-window . 

3) Depending on the measurement type, the measurement procedure shall be the following: 
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Short : The MT shall search for BCH of other interfering APs for at most for 5 frames (i.e. measurement 
window larger than 5 is not applicable). If found the BCH shall be decoded and RSSO [4] shall be measured 
on the BCH. If several BCHs are found the strongest RSSO value should be stored for reporting. The MT also 
stores part of the BCH content for reporting. See description of corresponding measurement reports. 

Percentiles : Consecutive RSSl samples [4] with distance 8 )is shall be collected during the specified 

measurement-window. 

Complete : The MT shall tune to the new frequency and search for BCH of other interfering APs for at most 5 
frames. If found the BCH shall be decoded and RSSO [4] shall be measured on the BCH. If several BCHs are 
found the strongest RSSO value should be stored for reporting. Also parts of the decoded BCH content is 
stored for reporting. See description of corresponding measurement report. Also for the remaining time of the 
measurement window consecutive RSSl samples [4] with distance 8 )is shall be collected. The order of these 
two measurement phases is out of scope of the present document. 

4) The MT shall then tune to the original frequency /o The re tuning time is not included in the measurement- 
window. 

5) MT shall report the requested measurement results to the AP. The report shall be available at the latest 5 frames 
after the return to the current frequency. 



RLC_DFS_MEASUREMENT_SHORT_ 
REQUEST or 

RLC_DFS_MEASUREMENT_PRECENTILES_ 
REQUEST or 



RLC_DFS_MEASUREMENT_COMPLETE_ 

REQUEST 

„, .1, I . oou r.c-c'n Tuning shall be ready and MT starts 
Store the last own BCH RSSO " . » j , 



The report shall be ready to be sent 1 
tuning frame and 5 frames after 
measurement on requested frequence Measurement Window ending point 

MT starts tuning to /^ MT starts tuning back to its own 

requested frequency y"^ frequency and resynchronises to the API 



- start-of-measuremenh 



Max 
1ms 



• • • 



Max J 
"lms^ 



• • • 



h- 



measurement-window 
(0-63 frames) 



'H 



h Measurement Time 

{measurement-window+ 2 tuning frames) 



H 



H-{start-of-measurement+ measurement-window+ 2 tuning frames-i- 5 frames)-W 

Figure 4: The measurement on other frequencies 

The start-of-measurement value is counted from the frame, where the message was received (i.e. next frame is frame 0) . 

Start-of-measurement shall not be smaller than 2 MAC frames i.e. the AP can not expect the MT to start tuning to the 
new frequency until two frames after the measurement request was transmitted. The example above depicts the scenario 
when start-of-measurement=2. 

The AP should not schedule any data to the measuring MT during the measurement time. The measurement time shall 
be from the start-of-measurement frame (belonging to measurement): 

measurement-window + 2 frames. 

NOTE: The 2 frames extra are for tuning and retuning time. 
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5.2.2.4.2.2 Measurements on used frequency 

When the AP needs measurements on the used frequency to be done by MT, the AP shall send one of the three 
measurement requests. The procedures shall be according to A or B below: 



A 



If the AP sends the RLC_DFS_MEASUREMENT_COMPLETE_REQUEST or 

RLC_DFS_MEASUREMENT_SHORT_REQUEST, the AP shall set the empty space for measurements 
by transmitting the RLC_AP_ABSENCE message and entering into the AP_Absence. 

The measurement-window shall be set in the request so that it defines a coarse interval during which the MT can 
expect to perform its measurement request. The real measurement is then triggered by the RLC_AP_ABSENCE 
message and the MT uses the beginning of the AP_ABSENCE interval as its start_of_measuring. The AP 
Absence interval should defined be within the measurement window. 

The measurement procedure is described below: 

1. The MT shall measure RSSO [4] for the last_own_bch_rss_level from the frame previous to the frame 
number start-of-measurement. 

2. Depending on the measurement type, the measurement shall be the following: 

Short : The MT shall search for BCH of other interfering APs during the AP Absence. If found the 
BCH shall be decoded and RSSO [4] shall be measured on the BCH. If several BCHs are found the 
strongest RSSO value should be stored for reporting. The MT also stores parts of the BCH content for 
reporting. 

Complete : The MT shall search for BCH of other interfering APs during the AP Absence. If found the 
BCH shall be decoded and RSSO [4] shall be measured on the BCH. If several BCHs are found the 
strongest RSSO value should be stored for reporting. The MT also stores parts of the BCH content for 
reporting. Also for the remaining time of the Absence period consecutive RSSl samples [4] with 
distance 8 )is shall be collected. The order of these two measurement phases is out of scope of the 
present document. 

3. MT shall report the requested measurement results to the AP. The report shall be available at the latest 
5 frames after end of measurement window. 



RLC_DFS_MEASUREMENT_SHORT_REQUEST 
RLC_DFS_MEASUREMENT_COMPLETE_REQU 
EST 



RLC AP ABSEN 



Store the last own BCH 
RSSO 



AP Absence starts 
(first frame after "last- 
mac-frame") 




MT ready to send the 
report 



-• • • • • 




* AP Absence ► 



-Start-of-measurement -►♦ 



-Measurement Window - 



►<— 5 frames- 



-MeasurementTime- 

Figure 5: Short or Complete measurement on used frequency 

The start-of-measurement value is counted from the frame, where the message was received (i.e. next frame is frame 0). 
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Start-of-measurement shall not be smaller than 2 MAC frames i.e. the AP can not expect the MT to start measuring until 
two frames after the measurement request was transmitted. The example above depicts the scenario when Start of 
Measurement=2. 

The AP shall make sure that the MT is notified of the start of the absence period at least 2 frames prior to the start of the 
actual measurement interval, (i.e. also this notification shall also be performed at least two frames beforehand). 

If the MT for some reason doesn't succeed in finding an AP Absence interval within the measurement-window it shall 
neglect the corresponding measurement request. 

The RLC_AP_ABSENCE message pointing to the measurement shall be sent before or in the same frame with the 
measurement request. 

NOTE: The AP should not schedule any data to the measuring MT during the measurement time. The 
measurement time shall be from the start-of-measurement frame (belonging to measurement): 

measurement-window 



B 



If the AP sends the RLC_DFS_MEASUREMENT_PERCENTILES_REQUEST there are two 
possibilities (Bl or B2). Both shall be supported by the MT: 

Bl: If the AP requires the MT to measure only the empty spaces of the frame, the AP shall indicate them 
by using FCH IE for indicating empty parts in the MAC frame[5]. 

The AP shall use the same technique as described in A. That is it only gives a coarse measurement 
window description in the measurement request and set the start-of-measurement to point out the frame, 
where the scheduling of the empty slots is expected to be started. 

The measurement procedure is described below: 

1. The MT shall measure RSSO [4] for the last_own_bch_rss_level from the frame previous to the frame 
number start-of-measurement. 

2. The MT shall collect the RSSl samples [4] with distance 8 \xs in all available empty spaces. 

3. MT shall report the requested measurement results to the AP. The report shall be available at the latest 
5 frames after end of measurement window. 



RLC_DFS_MEASUREMENT_PERC 
ENTILES REQUEST 



Store the last own 
BCH RSSO 



Empty parts = actual 

measurement 

intervals 




MT ready to send 
the report 



Start-of- 
measurement 



measurement-window 



5 frames 



Figure 6: Percentiles measurement on used frequency 

The start-of-measurement value is counted from the frame, where the message was received (the next frame is frame 
number 0). 

Start-of-measurement shall not be smaller than 2 MAC frames i.e. the AP can not expect the MT to start measuring until 
two frames after the measurement request was transmitted. 

The AP should not schedule any data to the measuring MT during the measurement time. The measurement time shall 
be from the start-of-measurement frame (belonging to measurement): 

measurement-window. 
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B2: The AP may also use AP Absence procedure as in case A. The AP is supposed not to use B 1 and B2 at 
the same time for a certain percentile measurement. 

5.2.2.4.3 MT measurement processing 

5.2.2.4.3.1 Measurement processing (field strengtin measurement) 

The RSS statistics specified in the measurement request shall be calculated and reported to the AP. 

5.2.2.4.3.2 Measurement processing (field strength measurement and BCH decoding) 

In addition to the RSS measurements described above, the MT may also be requested to decode the BCH of the 
measured frequency. In this case, the RSSO [4] of the BCH and parts of the BCH content shall also be reported to the 
AP. 

5.2.2.4.3.3 Indication of measurement time 

When the AP requests an MT to measure interference on the currently used frequency according to alternative B the AP 
shall indicate in the FCH where in the MAC frames the MT shall measure (i.e. where empty space is located). This shall 
be done by using a special information element (IE) type for this purpose, defined in [5]. 

5.2.2.4.4 Calculation of RSS statistics (informative) 

After the MT has collected RSS samples, statistical values are calculated by the MT and reported to the AP. The 
statistical values are percentiles of the interference. The percentile calculation is described below: 

The only possible RSS values are [0, -1, -2,. ..,-31] dB, as defined in [4]. 

NOTE: The RSS 1 are relative measurements that give the message outside of the BCH relative to a value 
RSS_REF, as described in the PHY reference mentioned. 

Thus, the percentiles can be calculated in the following way: 

1) Each RSS sample is placed in a bin, where the bins have values [0, -1, -2,. ..,-31] 

2) After all samples have been collected (250 samples/MAC frame) the value M is found, where M equals the 
maximum value m (dB) such that < x % of the samples have an RSS value < m. 

3) The value M equals the x % percentile 

EXAMPLE: Assume that there are the following RSS samples collected: 



RSS value (bin) 


No of samples 












-28 


4 


-29 


5 


-30 


7 


-31 






When 5 % percentile out of total 250 samples is needed to be calculated, the result will be M = -29, since 12 samples 
(4,8 %) He in the bins -31 - -29 and 16 samples (64 %) He in the bins -31 - -28. 
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5.2.2.5 DFS measurement reports 

MT shall report the RSS distribution at a given frequency relative to the latest performed RSSO measurement on the 
currently used frequency, which is also included in the message. If the MT decodes the BCH channel of another AP, it 
shall also include the following fields of the BCH, if it is requested by the AP; AP ID, Net ID, AP Tx power level. 
Traffic load. In addition the MT shall report RSSO of the decoded BCH. 

Diagram 49: DFS short report 



MSC dfs_report_short 

MT ENV 



MT RLC 



AP RLC 



AP ENV 



(RRC-DFS-REPORT-SHORT-ARG) 



RRC_dfs_report_short_rsp 



Active Mode 



RLC DFS REPORT SHORT 



; {frequency-index, 
omni-antenna-used, 
age-of-bch-measurement, 
last-own-bch-rx-level, 
bch-found, 
traffic-load, 
tx-level, 
ap-id, 
net-id, 
bch-rx-level} )_ 



RRC_dfs_report_short_cnf 



(FiRC-DFS-REPORT-SHORT-ARG) 



Active Mode 



Table 63: RLC-DFS-REPORT-SHORT 



RLC-DFS-REPORT-SHORT-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE, 


frequency-index 


FREQUENCY-INDEX, 


omni-antenna-used 


QMNI-ANTENNA-USED, 


age-of-measurement 


AGE-OF-MEASUREMENT, 


last-own-bch-rx-level 


LAST-OWN-BCH-RX-LEVEL, 


bch-found 


BCH-FOUND, 


traffic-load 


TRAFFIC-LOAD, 


ap-id 


AP-ID, 


tx-level 


TX-LEVEL, 


net-id 


NET-ID, 


bch-rx-level 


BCH-RX-LEVEL } 
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Diagram 50: DFS percentiles report 



MSC dfs_report_percentiles 

MT ENV I I MT^RLC 



AP_RLC 



AP ENV 



Active Mode 



RRC_dfs_report_percentiles_rsp 



;rrc-dfs-report-percentiles-arg ) 

rlc dfs report percentiles 



({frequency-index, 

omni-antenna-used, 

last-own-bch-rx-level, 

number-of-samples, 

rss-index-list, 

rss-statistics-list} 



T_dfs_measurement_percentiles_req 



RRC_dfs_report_percentiles_cnf 

►- 

(RRC-DFS-REPORT-PERCENTILES ARG 



Active_l\/lode 



Table 64: RLC-DFS-REPORT-PERCENTILES 



RLC-DFS-REPORT-PERCENTILES-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE, 


frequency-index 


FREQUENCY-INDEX, 


omni-antenna-used 


QMNI-ANTENNA-USED, 


last-own-bcli-rx-level 


LAST-OWN-BCH-RX-LEVEL, 


number-of-samples 


NUMBER-QF-SAMPLES, 


rss-index-list 


RSS-INDEX-LIST, 


rss-statistics-list 


RSS-STATISTICS-LIST } 



£75/ 



84 



ETSI TS 101 761-2 VI. 1.1 (2000-04) 



Diagram 51 : DFS complete report 



MSC dfs_report_complete 

MT ENV I I MT RLC 



AP RLC 



AP ENV 



Active Mode 



RRC_dfs_report_complete_rsp 



(RRC-DFS-REPORT-COMPLETE-ARG ) 

RLC_DFS_REPORT_COMPLETE 



({frequency-index, 
omni-antenna-used, 
age-of-bch -measurement, 
last-own-bcti-rx-level, 
bcti-found, 
traffic-load, 
ap-id, 
tx-level, 
net-id, 
bcti-rx-level, 
number-of-samples, 
rss-index-list, 
rss-statistics-list} ) 

Active Mode 



RRC_dfs_report_complete_cnf 



(RRC-DFS-REPORT-COMPLETE-AF G 



Table 65: RLC-DFS-REPORT-COMPLETE 



RLC-DFS-REPORT-COMPLETE-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE, 


frequency-index 


FREQUENCY-INDEX, 


omni-antenna-used 


QMNI-ANTENNA-USED, 


age-of-measurement 


AGE-QF-MEASUREMENT, 


last-own-bch-rx-level 


LAST-OWN-BCH-RX-LEVEL, 


bcli-found 


BCH-FOUND 


traffic-load 


TRAFFIC-LOAD, 


ap-id 


AP-ID, 


tx-level 


TX-LEVEL, 


net-id 


NET-ID, 


bch-rx-level 


BCH-RX-LEVEL, 


number-of-samples 


NUMBER-QF-SAMPLES, 


rss-index-list 


RSS-INDEX-LIST, 


rss-statistics-list 


RSS-STATISTICS-LIST } 



5.2.2.6 Change Frequency 

The AP shall broadcast the RLC_CHANGE_FREQUENCY message, before changing the operating frequency. The AP 
should use the MAC broadcast sleep group frames for broadcasting the RLC_CHANGE_FREQUENCY message. 

The AP shall transmit the RLC_CHANGE_FREQUENCY message in RBCH more than once before the change of 
frequency. 
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Diagram 52: Change Frequency procedure 
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Table 66: RLC-CHANGE-FREQUENCY 



RLC-CHANGE-FREQUENCY-ARG ::= SEQUENCE { 
ric-pdu-type RLC-SCH-PDU-TYPE, 
last-mac-frame LAST- MAC- FRAME, 
first-mac-frame FIRST-MAC-FRAME, 
frequency-index FREQUENCY-INDEX} 



5.2.3 Transmission Power Control 
5.2.3.1 Uplink power control 

The MT shall operate with a transmission power >-15 dBm. The maximum output power is an arbitrary power level 
within the regulatory requirements. The transmission power range shall be composed of power steps equal to or smaller 
than 3 dB, and the transmitting MT shall ensure that the power levels shall provide monotonia transmission power. The 
MT shall define its' transmission power level at the ARP as: 

min (AP_Tx_Level - MT_received_power_level + AP_Rx_UL_LevelH-E(PC_Offset), AP_Tx_Level, 
maximum output power of MT) 

where AP_Tx_Level denotes access point transmit power level and AP_Rx_UL_Level stands for the power level the 
access point is expecting to receive for all uplink signals. These values are transmitted as part of the BCH 
information [3]. MT_received_power _level is the estimated power level of the signal received by the MT. 
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JjPC_Offset) is the sum of the received PCjOjfset values from the AP. It is optional for AP to send PCjOjfset values. 
The algorithm when to send the RLC_UPLINK_PC_CALIBRATION message is vendor specific issue. To send the 
PC_Ojfset value, AP shall use the RLC_UPLINK_PC_CALIBRATION message dedicated to a single MT. When no 
PC_Ojfset value has been received from the AP, the value 2jPC_0ffset) = shall be used. The maximum minimum 
values for IjPCjOjfset) shall be +15 and -20 dB, respectively. The RLC_UPLINK_PC_CALIBRATION message 
shown in table 67 may be transmitted from the AP to the MT at any time after association. When a handover to another 
AP is performed by the MT, a PC-reset is performed, i.e. X(PC_Ojfset) = 0. The AP may also force a PC-reset at any 
time. No reset is performed at sector handover. The MT shall apply the updated X(PC_Ojfset) value no later than 2 
MAC frames after the frame where the RLC_UPLINK_PC_CALIBRATION message was received. When the AP has 
transmitted an RLC_UPLINK_PC_CALIB RATION message to a MT, AP shall wait at least 10 MAC frames until the 
next calibration message may be transmitted to the MT. 

Diagram 53: Uplink power control calibration 



MSC uplink_pc_calibration 



MT_ENV 




MT_RLC 




AP_RLC 




AP_EKV 
























<f Acti\e_irDde \ 




RRC_ui^ink_pc_ca]ibration_ind 


ijC_uplink_pc_calb ration 


RRC_iiplink_pc_calibration_ieq 






( {mac-id, 
pc-offeetj) 






({pc -offset 1) 






{ {mac -id, 
pc-offeet}) 




<^ Acti\e_irDde \ 



Table 67: RLC-UPLINK-PC-CALIBRATION 



RLC-UPLINK-PC-CALIBRATION-ARG ::= SEQUENCE { 
ric-pdu-type RLC-SCH-PDU-TYPE, 
pc-offset PC-OFFSET } 



5.2.3.2 Downlink Power Control 

Downlink power control is an implementation specific issue. In order to avoid interoperability problems the following 
restrictions apply to the default/normal downlink power control operation: 

• The AP shall use the power levels and accuracy specified in [4]. 

• The AP power can be decreased rapidly (3 dB/frame) without limitation on the dynamic range. 

• The AP transmitter power shall not be changed more than 3 dB between two consecutive MAC frames. 

• The AP shall not increase the transmitter power more than three steps (9 dB) during any 5 minute interval. 

• The AP shall ensure that it is compliant with the maximum allowed transmitted power for the center frequency 
where it is operating. 
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Spectrum regulatory requirements states that the interference to other radio systems than Hiperlan/2 shall be reduced as 
far as possible, but at least with 3 dB in average compared to transmission at full power by all APs and all MTs. This 
requirement implies that the AP should posses some degree of DL power control functionality. 

5.2.3.3 Direct Link Power Control (OAP/OMT) 

The MT shall be able to operate with a transmission power >= -15 dBm. The accuracies are given in [4]. 

A fixed power control shall be supported by all MTs and the AP/CC in DM. This fixed power control requires that each 
DM capable device shall set its transmission power level 3 dB below the maximum allowed transmitted power for the 
center frequency where it is operating (see subclause 5.8.1.1 in [4]). The usage of this fixed power control is only 
mandatory, if DiL power control using any other algorithm is not possible. Business or Home Environment Extensions 
may specify a more accurate DiL power control scheme. 

5.2.4 MT Alive 

This function is used for checking that an MT and an AP can communicate with each other. In turn, this shall be used for 
deciding on whether the AP and the MT are still associated to each other and on whether a MAC ID is free to use or 
occupied.. 

If the AP sends RLC_MT_ALIVE_REQUEST message, the MT shall respond with the 
RLC_MT_ALIVE_REQUEST_ACK. 

The AP should set mt-alive-interval time for the MT in the RLC_MT_ALIVE_REQUEST message. The MT shall 
respond to this message by sending RLC_MT_ALIVE_REQUEST_ACK message. Within the set interval, the MT shall 
send the RLC_MT_ALIVE message periodically to remain associated. 

NOTE 1: The AP may also send the RLC_MT_ALIVE_REQUEST periodically, which should be the same period 
that the AP has set to the MT. 

NOTE 2: If the mt-alive-interval is set to zero, the MT is not expected to send the RLC_MT_ALIVE message 
periodically, but the AP is expected to take care of the MT Alive function. 

If the MT does not respond within the given period with the RLC_MT_ALIVE message, the AP should send the 
RLC_MT_ALIVE_REQUEST message to the MT. If the MT does not respond with 

RLC_MT_ALIVE_REQUEST_ACK when requested, the AP should remove the association of the particular MT 
(implicit disassociation procedure, no Disassociation message exchange). 

There is a possibility to increase the number of failed MT Alive procedures (retransmissions included) before 
Disassociation takes place. The number can be from one to four failures. 

NOTE 3: When the MT sends MT_ALIVE_REQUEST it becomes active. 
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Diagram 54: MT alive procedure - AP initiated 



MSC MT Alive AP initiated 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



Active_mode_or_Sleep_mode 



RRC_mt_alive_request_ind 


RLC_MT_ALIVE_REQUEST 


({mt-alive-interval}) 
RLC_MT_ALIVE_REQUEST_ACK 


( {mac-id, 
mt-alive-interval}) 

RRC_mt_alive_request_rsp 


({mac-id, 
mac-id} ) 


({mac -id}) 



RRC_mt_alive_request_req 

( {mac-id, 

mt-allve-lnterval}) 



T_mt_alive_request 



RRC_mt_allve_request_cnf 

({mac-Id, 

mac-id} ) 



Active mode 



Table 68: RLC-IVIT-ALIVE-REQUEST 



RLC-IVIT-ALIVE-REQUEST-ARG ::= SEQUENCE { 
ric-pdu-type RLC-SCH-PDU-TYPE, 

mt-alive-interval MT-ALIVE-INTERVAL OPTIONAL } 



Table 69: RLC-MT-ALIVE-REQUEST-ACK 



RLC-MT-ALIVE-REQUEST-ACK-ARG :> 


= SEQUENCE { 


rIc-pdu-type 


RLC-SCH-PDU-TYPE, 




mac-id 


MAC-ID } 
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Diagram 55: MT alive procedure - IVIT initiated 



MSC MT Alive MT initiated 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



Active_Mode_or_Sleep_Mode 



RRC_mt_alive_req 
({mac-id}) 



T_mt_alive 
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RLC_MT_ALIVE_ACK 
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*- 

({mac-id}) 

R RC_mt_alive_rs p 

-* 

({mac-id}) 



RRC_mt_alive_cnf 



({mac-id}) 



Active mode 



Table 70: RLC-IVIT-ALIVE 



RLC-MT-ALIVE-ARG ::= SEQUENCE { 
ric-pdu-type RLC-SCH-PDU-TYPE, 
mac-id MAC-ID } 



Table 71 : RLC-MT-ALIVE-ACK 



RLC-MT-ALIVE-ACK-ARG ::= SEQUENCE { 
rIc-pdu-type RLC-SCH-PDU-TYPE } 



5.2.5 MT Absence (OAP/OMT) 

This procedure is used by the MT to announce that it is temporary unavailable for the current AP, e.g. in order to 
perform measurements on neighbouring APs. During this time, no communication between MT and the current AP is 
possible. 

The MT should inform the AP that it will be absent with the RLC_MT_ABSENCE message and tell the absence time. 
The AP shall respond with the RLC_MT_ABSENCE_ACK message. The absence time is started from the frame the 
RLC_MT_ABSENCE_ACK is received (the next frame is number 1 etc.). During this time the MT and the AP cannot 
communicate.. After the absence period (n frames) the MT and AP shall immediately continue with normal operation. 
After this period the MT shall execute the MT Alive sequence, if the MT has no data is to be transmitted. In all cases the 
AP may send the RLC_MT_ALIVE_REQUEST message after the absent period to check if the MT is available. 

NOTE 1 : The AP should take care of it's own processing delays, when counting the returning moment of the MT. 

NOTE 2: The MT should take care of it's own processing delays, when counting the returning moment to the AP. 
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Diagram 56: MT absence procedure 
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Table 72: RLC-MT-ABSENCE 



RLC-MT-ABSENCE-ARG ::= SEQUENCE { 
ric-pdu-type RLC-SCH-PDU-TYPE, 
mt-absence-time MT-ABSENCE-TIME, 
mac-id MAC-ID} 



Table 73: RLC-MT-ABSENCE-ACK 



RLC-ABSENCE-ACK-ARG ::= SEQUENCE { 
ric-pdu-type RLC-SCH-PDU-TYPE } 



5.2.6 Power Saving (OMT) 



5.2.6.1 General 

To allow reduced power consumption for mobile terminals the power save function can be used. 

A mobile can enter one out of sixteen different sleep groups to reduce its power consumption. The term sleep mode is 
used to refer to a mobile that has joined one of the sleep groups. 

A mobile terminal in sleep mode shall monitor the BCCH content periodically, as opposed to active mode where mobile 
terminal shall monitor the BCCH in every frame. The term wake-up frame refers to the frame where the mobile terminal 
in sleep mode monitors the BCCH. 
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The AP/CC should maintain an internal sleep state for each MT being either active or sleep. The MT should maintain an 
internal sleep state being either active or sleep. 

In order to enter sleep mode the MT shall request the AP by sending a RLC_SLEEP message and receive a positive 
acknowledgement in RLC_SLEEP_ACK message. 

The sleep state shall be changed to sleep at the AP at the transmission of the RLC_SLEEP_ACK message. The sleep 
state should be changed to sleep at the MT at the reception of the RLC_SLEEP_ACK message indicating an acceptance 
to enter sleep mode. 

The AP should change the sleep state to active at arbitrary message reception from an MT with current sleep state 
active. The MT shall change its sleep state to active at decoding of the FCCH IE with a matching MAC ID that 
corresponds to the MT's MAC ID if current sleep state is sleep. The MT shall change its sleep state to active at arbitary 
message transmission. 

NOTE 1 : As is given by the rules above for sleep ^ active transitions, the MT will always be in active state if it 
receives an arbitrary unicasted message. 

NOTE 2: According to the rules above will broadcasted or multicasted messages, i.e. UBCH, UMCH and RBCH, 
not cause any change of sleep state for an MT. 

Sixteen sleep groups exists, where the sleep mode periodicity is given by: 

2" with (1 < n < 16) with the unit frames. 

The AP shall coordinate the sleep groups such that the periodicity for all sleep groups coincide with the periodicity for 
sleep group with n=l. The latter will guarantee that for arbitrary sleep group m (m > 1), all sleep groups with shorter 
periodicity will at regular interval have their wake up frames equal to wake up frame for sleep group m. 

An MT in sleep mode shall monitor the BCCH at the wake-up frames that corresponds to the sleep group. Upon such a 
wake-up frame, if the BCCH DST [5] indication is active, the MT shall proceed to decode the FCCH. The FCCH may 
indicate a change of sleep state to active, or may indicate the presence of granted UBCH or UMCH in the frame. The 
DST indication also requires the MT to decode the following frame and apply the same decoding rules as for the current 
wake up frame. The BCCH may also contain an DL RBCH Indicator, that when set active requires the MT to decode the 
FCCH. The wakeup will in that case contain a granted RBCH. 

The AP shall internally select a MAC broadcast sleep group, denoted n^p, out of a subset from the sixteen sleep groups. 
An exemplatory wake-up frame for the MAC broadcast sleep group is denoted MAC broadcast frame. 

The periodicity of the MAC broadcast sleep group is given by: 

2"^^ with (5 < n < 16) with the unit frames. 

MAC broadcast frames can be used by the AP to transmit multicast and broadcast data since the wake-up frame for all 
MTs in sleep mode, with sleep group n <_nAp, will coincide with MAC broadcast frames. 

The AP may transmit multicast and broadcast data in the following frames after a MAC broadcast frame by using the 
DST indication in the BCCH set active until the transmission is completed. The MTs will then revert to their 
active/sleep state they had prior to the MAC broadcast frame. This allows for a scalable broadcast and multicast 
bandwidth for sleeping MTs. 

For MTs with a sleep group n < nAp, the wake-up frames in between the MAC broadcast frames are denoted 
subBroadcast frames. 
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Diagram 57: Power saving procedures 
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Figure 7: Example of the MAC Broadcast frames and subBroadcast frames 

NOTE: In the example the MT3 listens only the MAC broadcast frames (repeated once per N frames), the MT2 
has a sleep mode period of N/2 frames and the MTl has a sleep mode period of N/4 frames. Thus, the 
MT2 listens to MAC broadcast frames and always one subBroadcast frame between MAC broadcast 
frames. The MTl listens to three subBroadcast frames between MAC broadcast frames. The interval of 
subBroadcast frames is the result of allocating different, but synchronized sleep mode periods for MTs. 
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5.2.6.2 MT sleep request procedure 

The MT shall not send RLC_SLEEP message (enter the sleep mode) during the association and handover procedures, 

see 5.1.1, 5.2.1. 

Apart from the exception above, the MT may at any time request to enter sleep mode, by sending the RLC_SLEEP 
message. The message shall contain a proposed sleep-group. The sleep-group shall be: 

1 < Sleep-group < 16 

NOTE: The corresponding sleep mode periodicity is 2'' '='=P"S""p yyith tjje unit frames. 

Based upon the internally selected MAC broadcast sleep group, nAp, the AP shall determine the sleep group according to 
the ft)llwing formulas: 

• If sleep-group <_nAp, then the sleep group for the MT shall be equal to the proposed sleep-group. 

• If sleep-group > n^p, then the sleep group for the MT shall be equal to nAp. 

Since the MT may request for sleep mode at any frame the AP shall set an offset parameter to align the MT to coincide 
with the periodicity that the AP has for the selected sleep-group. 

The offset parameter shall be the number of frames after the current frame, in which the RLC_SLEEP_ACK is 
transmitted, that shall elapse until the first wake-up frame appears for the selected sleep-group. 

<_Offset < (2'''''i'-f<'-""P - 1) with the unit frames. 

Example: The AP has determined the sleep-group for an MT to be 2, with a sleep mode periodicty of 4 

frames. 

If the RLC_SLEEP_ACK is transmitted in the wake-up frame for the sleep group, the offset 
parameter will be equal to 3. 

If the RLC_SLEEP_ACK is transmitted in the frame prior to the wake-up frame for the sleep 
group, the offset parameter will be equal to 0. 

If the AP sets the sleep-group to zero, the MT shall not enter sleep mode. 

The response to a RLC_SLEEP shall be sent in RLC_SLEEP_ACK. 
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Diagram 58: Sleep request procedure 
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Table 74: RLC-SLEEP 



RLC-SLEEP-ARG ::= 


SEQUENCE { 


ric-pdu-type 


RLC-SCH-PDU-TYPE, 


sleep-group 


SLEEP-GROUP, 


care-of-broadcast 


CARE-OF-BROADCAST, 


mac-id 


MAC-ID } 



Table 75: RLC-SLEEP-ACK 



RLC-SLEEP-ACK-ARG 


::= SEQUENCE! 


rIc-pdu-type 


RLC-SCH-PDU-TYPE, 


sleep-group 


SLEEP-GROUP, 


care-of-broadcast 


CARE-OF-BROADCAST, 


offset 


FRAME-NUM } 



5.2.6.3 AP Procedure 

5.2.6.3.1 AP Procedure for unicast data 

At the occurrence of pending unicast data to an MT with sleep state equal sleep, the AP shall initiate an AP wake-up 
procedure of the MT prior to transmission of the unicast data. The AP wake-up procedure shall occur at arbitrary 
wake-up frame for the corresponding sleep-group for the MT. 
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At the wake-up frame, the AP shall: 

1) Set the DST indication active in the BCCH [5]. 

2) Allocate one uphnk RG for DCCH (DLCC ID = 0) with one granted SCH for the corresponding MT. 

In order to improve the response probability from a MT in sleep, the AP may repeat the AP wake-up procedure at the 
subsequent frame after the wake-up frame. More generally, since the MT wake-up procedure is repeated until the DST 
indication is inactive, the AP may repeat the AP wake-up procedure at arbitrary frame until the DST indication is 
inactive. 

At the reception of arbitrary data from an MT with sleep state sleep the AP should change the sleep state to active. 

5.2.6.3.2 AP Procedure for broadcast data 

At the occurrence of pending broadcast data (i.e. UMCH and/or UBCH), with exception for data transmitted in RBCH, 
the AP may defer transmission until the MAC broadcast frame. If used, the AP shall set the DST indication in the BCCH 
to indicate the possible presence of either UMCH or UBCH data in the frame. 

For broadcast data that spans over multiple MAC frames, or due to the use of repetition mode, the AP may use the 
bandwidth scalability option to send UMCH and/or UBCH data at subsequent frames after the MAC broadcast frame. 
The DST indication shall be set in all subsequent frames after the MAC broadcast frame until the UMCH and/or UMCH 
transmission is completed. 

NOTE: Due to the MT wake-up procedure, the AP does not necessarily have to transmit UBCH and/or UMCH 
data in a frame where the DST indication is active. 

If the AP does not use the MAC broadcast frame for the transmission of broadcast data (i.e. UMCH and/or UBCH), with 
exception for data transmitted in RBCH, the DST indication shall be inactive. 

At the occurrence of pending broadcast data transmitted in RBCH, the AP may defer transmission until a MAC 

broadcast frame, or arbitrary wake-up frame. 

The DL RBCH Indication in BCCH [5] shall be active for all frames where RBCH is transmitted. 

5.2.6.4 MT Procedure 

For an MT in sleep mode, the MT shall initiate the MT wake-up procedure at the wake-up frames for the corresponding 
sleep group. At the wake-up frame the MT shall decode the BCCH for the occurrence of the DST or DL RBCH 
indication [5]. 

If the DST indication is active and/or DL RBCH Indicator is active, the MT shall: 

1) Decode the FCCH: 

At the occurrence of an IE with MAC ID that corresponds to the MAC ID of the MT, the sleep state shall 
be set to active. 

NOTE 1 : An MT that changes its sleep state from sleep to active shall proceed according to the normal procedure 
for decoding FCCH. 

At the occurrence of UBCH and/or UMCH, the MT receives UBCH and/or UMCH in the frame. 

At the occurrence of RBCH, the MT receives the RBCH in the frame. 

2) Decode the BCCH in the following frame and restart the MT wake-up procedure. 

If the DST indication is inactive and DL RBCH Indication is inactive, and the MT sleep state is sleep, the MT 
should revert to its low power mode until the expiration of the next wake-up frame. 

At the occurrence of pending data transmission for an MT in sleep state sleep, the sleep state should be changed to 
active. 

NOTE 2: An MT with sleep state active will continue by transmitting a resource request, which will change the 
sleep state from sleep to active at the AP. Normal data transmission will follow. 
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Since it is likely that the MT from time to time will have failure in the CRC check of the BCH, or due to an internal MT 
error initiate the MT wake-up procedure at an incorrect frame. To mitigate the effect of the latter erroneous conditions 
the following rules shall be supported. 

If the CRC check of the BCH fails for a frame where MT wake-up procedure is started, the sleep state of the 
mobile shall be unchanged, and the MT shall re-start the wake-up procedure in the following frame. 

If the CRC check of the BCH for the following frame is successful, the MT wake-up procedure shall 
continue. 

If the CRC check of the BCH for the following frame fails, the MT sleep state should be set to active. 

If the frame counter in the BCCH differs from the frame counter in MT, the MT should align its own counter 
value according to the frame counter of the BCCH. 

NOTE 3: The MT has to take into account in which frame after the wake-up frame the MT wake-up procedure is 
started. 

5.3 Services supporting DUCC (DLC User Connection Control) 

This control function is responsible for setting up, maintaining, re-negotiating and closing a DLC user connection at the 
DLC layer. Its main functions are: 

• Allocating the DLCC-ID for a new specific connection. 

• Setting up the connection at DLC layer. 

The MT is not allowed to send any DUCC message before being associated to the AP. 



5.3.1 Unicast DUG Setup 



Unicast radio connection can be requested both by the AP and by the MT using the RLC_SETUP message. In the 
message the selected DLCC IDs and corresponding characteristics shall be included. 

The RLC_SETUP message may be sent at multiple occasions since the maximal numbers of DUCs are limited in the 
message. The duc-ext-ind shall be set inactive for the first RLC_SETUP message and active for all subsequent 
RLC_SETUP messages. 

NOTE 1 : The duc-ext-ind mechanism is especially relevant during the network handover procedure, when the 

number of DUCs that have to be re-established via the radio interface are more than what can be sent in 
one RLC_SETUP message. 

NOTE 2: DLCC IDs for mobile originating RLC_SETUP messages does not have to be set. The dlcc-id values 
proposed by an MT can be ignored by the AP. 

The RLC_SETUP message shall not be used to modify existing DUCs. 

If the receiver of the RLC_SETUP message being either the AP or the MT is not able to accept the proposal made by 
the sender, it shall send an RLC_CONNECT message containing the receiver's proposal. To accept the proposal made 
by the sender, the receiver shall repeat the proposal of the sender in the RLC_CONNECT message. In order to reject the 
RLC_SETUP the receiver shall send RLC_RELEASE message and continue with the Release procedure, as described in 
subclause 5.3.2. 

If the sender accepts the receivers proposal sent in the RLC_CONNECT message, the sender shall respond with 
RLC_CONNECT_ACK message. Otherwise the sender shall send RLC_RELEASE message and continue with the 
Release procedure, as described in 5.3.2. 

5.3.1 .1 AP Initiated DUG Setup (OAP/OMT) 

The AP can send RLC_SETUP message in order to establish unicast radio connections. In the message the selected 
DLCC IDs and corresponding characteristics shall be included. The AP sender shall not transmit downlink traffic to the 
DUCs that are included in the RLC_SETUP message until RLC_CONNECT message is received. 
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If the AP accepts the MT's proposal of the DUC's included in the RLC_CONNECT message, the AP shall respond with 
RLC_CONNECT_ACK message: 

At the reception of the RLC_CONNECT message, for the DUCs included in the RLC_CONNECT message, the AP 
shall: 

Discard all data in its reception buffer and optionally discard all data in its transmission buffer (the decision 
is vendor specific). 

- Set TxBoW and RxBoW to 0. 

If the sender and/or receiver are in flow control state, exit the flow control state. 

Clear all other ARQ state information, i.e. acknowledgement bitmaps. 

Set the DUC characteristics as included in the RLC_CONNECT message. 

If the AP does not accept the MT's proposal sent in the RLC_CONNECT message, the AP shall send the 
RLC_RELEASE message and continue with the Release procedure, as described in 5.3.2. 

If the MT is not able to accept the proposal made by the AP in the RLC_SETUP message, it shall send 
RLC_CONNECT message containing the MT's proposal. To accept the proposal made by the AP, the MT shall repeat 
the proposal of the AP in the RLC_CONNECT message. The MT sender shall not transmit uplink traffic to the DUCs 
that are included in the RLC_CONNECT message until RLC_CONNECT_ACK message is received. 

At the transmission of the of the RLC_CONNECT message, for the DUCs included in the RLC_CONNECT message, 
the MT shall: 

Discard all data in its reception buffer and optionally discard all data in its transmission buffer (the decision 
is vendor specific). 

- Set TxBoW and RxBoW to 0. 

If the sender and/or receiver are in flow control state, exit the flow control state. 

Clear all other ARQ state information, i.e. acknowledgement bitmaps and rtt awareness for resource request. 

Set the DUC characteristics as included in the RLC_CONNECT message. 

In order to reject the RLC_SETUP the MT shall send RLC_RELEASE message and continue with the Release 
procedure, as described in 5.3.2. 

NOTE: DLCC IDs for mobile originating RLC_SETUP messages does not have to be set. The dlcc-id values 
proposed by an MT can be ignored by the AP. 
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Diagram 59: Mobile terminated connection Setup procedure 
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Table 76: RLC-SETUP 



RLC-SETUP-ARG ::= 


SEQUENCE { 


rIc-pdu-type 

cl-id 

duc-ext-ind 

cl-conn-attr-lengtii 

duc-descr-list 


RLC-LCH-PDU-TYPE, 

CL-ID, 

DUC-EXT-IND, 

INTEGER(0..31), 

DUC-DESCR-LIST} 



Table 77: RLC-CONNECT 



RLC-CONNECT-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE, 

cl-id CL-ID, 

cl-conn-attr-length INTEGER(0..31), 

duc-descr-list DUC-DESCR-LIST } 



Table 78: RLC-CONNECT-ACK 



RLC-CONNECT-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE, 

cl-id CL-ID, 

cl-conn-attr-length INTEGER(0..31), 

dicc-descr-list DLCC-DESCR-LIST } 
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5.3.1 .2 MT initiated DUG Setup 

The MT can send RLC_SETUP message in order to establish unicast radio connections. In the message the selected 
DLCC IDs and corresponding characteristics shall be included. The MT sender shall not transmit uplink traffic to the 
DUCs that are included in the RLC_SETUP message until RLC_CONNECT message is received. 

If the MT accepts the AP's proposal of the DUCs included in the RLC_CONNECT message, the MT shall respond with 
RLC_CONNECT_ACK message: 

At the reception of the RLC_CONNECT message, for the DUCs included in the RLC_CONNECT message, the MT 
shall: 

Discard all data in its reception buffer and optionally discard all data in its transmission buffer (the decision 
is vendor specific). 

- Set TxBoW and RxBoW to 0. 

If the sender and/or receiver are in flow control state, exit the flow control state. 

Clear all other ARQ state information, i.e. acknowledgement bitmaps and rtt awareness for resource request. 

Set the DUC characteristics as included in the RLC_CONNECT message. 

If the MT does not accept the MT's proposal sent in the RLC_CONNECT message, the MT shall send the 
RLC_RELEASE message and continue with the Release procedure, as described in 5.3.2. 

If the AP is not able to accept the proposal made by the MT in the RLC_SETUP message, it shall send 
RLC_CONNECT message containing the MT's proposal. To accept the proposal made by the MT, the AP shall repeat 
the proposal of the MT in the RLC_CONNECT message. The AP sender shall not transmit downlink traffic to the DUCs 
that are included in the RLC_CONNECT message until RLC_CONNECT_ACK message is received. 

At the transmission of the of the RLC_CONNECT message, for the DUCs included in the RLC_CONNECT message, 
the AP shall: 

Discard all data in its reception buffer and optionally discard all data in its transmission buffer (the decision 
is vendor specific). 

- Set TxBoW and RxBoW to 0. 

If the sender and/or receiver are in flow control state, exit the flow control state. 

Clear all other ARQ state information, i.e. acknowledgement bitmaps. 

Set the DUC characteristics as included in the RLC_CONNECT message. 

In order to reject the RLC_SETUP the AP shall send RLC_RELEASE message and continue with the Release 
procedure, as described in 5.3.2. 
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Diagram 60: Mobile originated connection Setup procedure 
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If AP is not able to accept the proposal made by MT, it shall send RLC_CONNECT message containing AP's proposal. 
To accept the proposal made by the MT, the AP shall repeat the proposal of the MT in the RLC_CONNECT message. 
In order to reject the SETUP the AP shall send RLC_RELEASE message and continue with the Release procedure, as 
described in 5.3.2. 

If the MT accepts AP's proposal sent in the RLC_CONNECT message, the MT shall respond with 
RLC_CONNECT_ACK message. Otherwise the MT shall send RLC_RELEASE message and continue with the Release 
procedure, as described in 5.3.2. 

5.3.2 Unicast DUC release 
5.3.2.1 AP Initiated DUC Release 

In case of an AP Initiated Connection Release the AP shall send an RLC_RELEASE message commanding the MT to 
release one or multiple unicast DUCs. In this message the AP shall indicate to the MT the selected DLCC IDs of the 
respective DUCs. 
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Diagram 61 : Mobile terminated connection release procedure 
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Table 79: RLC-RELEASE 



RLC-RELEASE-ARG ::= SEQUENCE { 



ric-pdu-type 

dicc-id-list 

release-cause 



RLC-LCH-PDU-TYPE, 
DLCC-ID-LIST, 

RELEASE-CAUSE } 



Table 80: RLC-RELEASE-ACK 



RLC-RELEASE-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type 
dicc-id-list 



RLC-LCH-PDU-TYPE, 
DLCC-ID-LIST} 



The MT shall respond with RLC_RELEASE_ACK indicating that the relevant DLCC IDs are released. 

5.3.2.2 MT Initiated DUC release 

In case of an MT Initiated Connection Release the MT shall send an RLC_RELEASE message requesting the AP to 
release one or multiple unicast DUCs. In this message the MT shall indicate to the AP the selected DLCC IDs of the 
respective DUCs. 
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Diagram 62: Mobile originated connection release procedure 



MSC Release_Radio_Connection_mobile_originated 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



DUG established 





DUC_release_req 


RLC_RELEASE 


DUC_release_ind 






(DUC-RELEASE-ARG) 






> 
T_release_mt 

DUC_release_ 


\ 


({dicc-id-list, 
release-cause}) 

RLC_RELEASE_ACK 






(DUC-RELEASE-ARG) 

DUC_release_rsp 






( DUC-RELEASE-ACK-ARG) 






({dicc-id-list}) 






( DUC-RELEASE-ACK-ARG) 





DUC_released 



The AP shall respond with RLC_RELEASE_ACK indicating that the relevant DLCC IDs are released. 

5.3.3 Unicast DUG modify (OAP/OMT) 

Existing unicast radio connection can be modified by both the AP and by the MT using the RLC_MODIFY_REQ 
message. In the message the selected DLCC IDs of the respective unicast DUCs and their new characteristics shall be 
included. 

The RLC_SETUP message may be sent at multiple occasions changing the characteristics for the same DUC. 

The RLC_MODIFY_REQ message shall be used to modify existing DUCs. 

If the receiver of the RLC_MODIFY_REQ message being either the AP or the MT is not able to accept the proposal 
made by the sender, it shall send an RLC_MODIFY message containing the receiver's proposal. To accept the proposal 
made by the sender, the receiver shall repeat the proposal of the sender in the RLC_MODIFY message. 

If the sender accepts the receivers proposal sent in the RLC_MODIFY message, the sender shall respond with 
RLC_MODIFY_ACK message. Otherwise the sender shall send RLC_RELEASE message and continue with the 
Release procedure, as described in 5.3.2. 

5.3.3.1 AP Initiated DUC modify 

The AP can send RLC_MODIFY_REQ message in order to modify existing unicast radio connections. In the message 
the selected DLCC IDs of the respective unicast DUCs and their new characteristics shall be included. The AP sender 
shall either stop transmitting downlink traffic to the DUCs that are included in the RLC_MODIFY_REQ message, or 
transmit dummy PDUs, until RLC_MODIFY message is received. 

If the AP accepts the MT's proposal of the DUCs included in the RLC_MODIFY message, the AP shall respond with 
RLC_MODIFY_ACK message: 

At the reception of the RLC_MODIFY message, for the DUCs included in the RLC_MODIFY message, the AP shall: 

Discard all data in its reception buffer and optionally discard all data in its transmission buffer (the decision 
is vendor specific). 

- Set TxBoW and RxBoW to 0. 
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If the sender and/or receiver are in flow control state, exit the flow control state. 

Clear all other ARQ state information, i.e. acknowledgement bitmaps. 

Set the DUC characteristics as included in the RLC_MODIFY message. 

If the AP does not accept the MT's proposal sent in the RLC_MODIFY message, the AP shall send the RLC_RELEASE 
message and continue with the Release procedure, as described in 5.3.2. 

If the MT is not able to accept the proposal made by the AP in the RLC_MODIFY_REQ message, it shall send 
RLC_MODIFY message containing the MT's proposal. To accept the proposal made by the AP, the MT shall repeat the 
proposal of the AP in the RLC_MODIFY message. The MT sender shall either stop transmitting uplink traffic to the 
DUCs that are included in the RLC_CONNECT message, or transmit dummy PDUs, until RLC_MODIFY_ACK 
message is received. 

At the transmission of the of the RLC_MODIFY message, for the DUCs included in the RLC_MODIFY message, the 
MT shall: 

Discard all data in its reception buffer and optionally discard all data in its transmission buffer (the decision 
is vendor specific). 

- Set TxBoW and RxBoW to 0. 

If the sender and/or receiver are in flow control state, exit the flow control state. 

Clear all other ARQ state information, i.e. acknowledgement bitmaps and rtt awareness for resource request. 

Set the DUC characteristics as included in the RLC_MODIFY message. 
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Diagram 63: Mobile terminated connection modify procedure 



MSC Modify_Radio_Connection_mobile_term inated 



MT ENV 



MT RLC 



AP RLC 



AP ENV 



DUG established 



DUC_modifyreq_ind 



( DUC-MODIFY-REQ-ARG 
DUC_modify_req 



'DUC-MODIFY-ARG 



T_modify_mt 



DUC_modify_cnf 



( DUC-MODIFY-ACK-ARG ; 



RLC MODIFY REG 



( {duc-ext-ind, 

cl-conn-attr-length, 

duc-descr-list}) 



RLC MODIFY 



({cl-conn-attr-length, 
duc-descr-list} 



RLC MODIFY ACK 



; {cl-conn-attr-length, 
dicc-descr-list}) 



DUC_modifyreq_req 



(DUC-MODIFY-REQ-ARG 



T_modify_req_ap 



DUC_modify_ind 



(DUC-MODIFY-ARG ) 

DUC_modify_rsp 



( DUC-MODIFY-ACK-ARG ) 



DUG established 



Table 81 : RLC-l\flODIFY-REQ 



RLC-MODIFY-REQ-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE, 

duc-ext-ind DUC-EXT-IND, 

cl-conn-attr-length INTEGER(0..31), 

duc-descr-list DUC-DESCR-LIST } 



Table 82: RLC-MODIFY 



RLC-MODIFY-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE, 

cl-conn-attr-length INTEGER(0..31 ), 
duc-descr-list DUC-DESCR-LIST } 



Table 83: RLC-l\flODIFY-ACK 



RLC-MQDIFY-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE, 

cl-conn-attr-length INTEGER(0..31), 
dicc-descr-list DLCC-DESCR-LIST } 
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5.3.3.2 MT Initiated DUG modify 

The MT can send RLC_MODIFY_REQ message in order to modify existing unicast radio connections. In the message 
the selected DLCC IDs of the respective unicast DUCs and their new characteristics shall be included. The MT sender 
shall either stop transmitting downlink traffic to the DUCs that are included in the RLC_MODIFY_REQ message, or 
transmit dummy PDUs, until RLC_MODIFY message is received. 

If the MT accepts the MT's proposal of the DUCs included in the RLC_MODIFY message, the MT shall respond with 
RLC_MODIFY_ACK message: 

At the reception of the RLC_MODIFY message, for the DUCs included in the RLC_MODIFY message, the MT shall: 

Discard all data in its reception buffer and optionally discard all data in its transmission buffer (the decision 
is vendor specific). 

- Set TxBoW and RxBoW to 0. 

If the sender and/or receiver are in flow control state, exit the flow control state. 

Clear all other ARQ state information, i.e. acknowledgement bitmaps and rtt awareness for resource request. 

Set the DUC characteristics as included in the RLC_MODIFY message. 

If the MT does not accept the MT's proposal sent in the RLC_MODIFY message, the MT shall send the 
RLC_RELEASE message and continue with the Release procedure, as described in 5.3.2. 

If the AP is not able to accept the proposal made by the MT in the RLC_MODIFY_REQ message, it shall send 
RLC_MODIFY message containing the AP's proposal. To accept the proposal made by the MT, the AP shall repeat the 
proposal of the MT in the RLC_MODIFY message. The AP sender shall either stop transmitting uplink traffic to the 
DUCs that are included in the RLC_CONNECT message, or transmit dummy PDUs, until RLC_MODIFY_ACK 
message is received. 

At the transmission of the of the RLC_MODIFY message, for the DUCs included in the RLC_MODIFY message, the 
AP shall: 

Discard all data in its reception buffer and optionally discard all data in its transmission buffer (the decision 
is vendor specific). 

- Set TxBoW and RxBoW to 0. 

If the sender and/or receiver are in flow control state, exit the flow control state. 
Clear all other ARQ state information, i.e. acknowledgement bitmaps. 
Set the DUC characteristics as included in the RLC_MODIFY message. 



£75/ 



106 



ETSI TS 101 761-2 VI. 1.1 (2000-04) 



Diagram 64: Mobile originated connection modify procedure 



MSC Modify_Radio_Connection_mobile_originated 

MT ENV I I MT RLC 



AP RLC 



AP ENV 



DUC_established 



DUC_modifyreq_req 



(DUC-MODIFY-REQ-ARG ) 

T_modify_req_mt 



RLC MODIFY REQ 



({duc-ext-ind, 
cl-conn-attr-length, 
duc-descr-list} ) 



DUC_modifyreqJnd 



(DUC-MODIFY-REQ-ARG ) 

DUC_modify_req 



RLC_MODIFY 



(duc-modify-arg; 



DUC_modify_ind 



({cl-conn-attr-length, ^ 
duc-descr-list}) 



(DUC-MODIFY-ARG) 



T_modify_ap 



DUC_modify_rsp 



(DUC-MODIFY-ACK-ARG 



RLC MODIFY ACK 



({cl-conn-attr-length, 
dicc-descr-list} ) 



DUC_established 



DUC_modify_cnf 



(DUC-MODIFY-ACK-ARG ) 



The DUCs shall be reset, see subclause 5.3.4. 

5.3.4 Unicast DUG Reset 

With the reset procedure the ARQ instances and related timers of one or more unicast DUCs shall be reset to their initial 
state. The DUC characteristics as agreed upon Setup or latest modification shall be maintained. The reset procedure 
shall be initiated by sending the RLC_RESET message including the DLCC ID(s) of the DUCs. The receiving entity 
(either MT or AP) shall acknowledge the Reset by responding with RLC_RESET_ACK indicating the corresponding 
DLCC ID(s). 

The ARQ sequence number of the established DUCs shall be reset to zero both in the MT and the AP. At the receiving 
entity (either MT or AP) RxBoW shall be reset to zero at the reception of the RLC_RESET message. At the sending 
entity (either MT or AP) TxBoW shall be reset to zero at the reception of the RLC_RESET_ACK message. 

A sender shall not send a duplicate RLC_RESET until RLC_RESET_ACK for this particular DUC is received or until 
the retransmit timer {T_reset_ap or T_reset_mt) expires. 

NOTE: The reset does only affect either uplink or downUnk direction. 

5.3.4.1 AP Initiated DUC Reset 

The AP sender shall either stop transmitting downlink traffic related to the DUCs that are included in the RLC_RESET 
message after sending the RLC_RESET (including the current frame), or transmit dummy PDUs. The AP should not 
start transmitting downlink traffic related to the DUCs that are included in the RLC_RESET message before 
RLC_RESET_ACK is received. The AP shall reset the ARQ instance immediately after receiving RLC_RESET_ACK. 
The MT shall reset the ARQ instance immediately after receiving RLC_RESET. 

At the reception of RLC_RESET, for the DUCs that are included in the RLC_RESET message, the MT shall: 

• Discard all data in its reception buffer. 
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• Set RxBoW to 0. 

• If the receiver is in flow control state, exit the flow control state. 

• Clear all other ARQ state information, i.e. acknowledgement bitmap. 

• Retain all DUC characteristics as agreed upon Setup or latest modification. 

At the reception of RLC_RESET_ACK, for the DUCs that are included in the RLC_RESET message, the AP shall: 

• Optionally discard all data in its transmission buffer (the decision is vendor specific). 

• Set TxBoW to 0. 

• If the sender is in flow control state, exit the flow control state. 

• Clear all other ARQ state information, i.e. rtt awareness for resource requests. 

• Retain all DUC characteristics as agreed upon Setup or latest modification. 

The AP shall not retransmit a duplicate RLC_RESET message, until either the retransmit timer expires or until the 
RLC RESET ACK is received. 



Diagram 65: Mobile terminated reset procedure 



MSC Reset_mobile_terminated 
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Table 84: RLC-RESET 



RLC-RESET-ARG ::= SEQUENCE { 



ric-pdu-type 
dlcc-id-list 



RLC-LCH-PDU-TYPE, 
DLCC-ID-LIST} 



Table 85: RLC-RESET-ACK 



RLC-RESET-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type 
dlcc-id-list 



RLC-LCH-PDU-TYPE, 
DLCC-ID-LIST} 
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5.3.4.2 MT Initiated DUG reset 



The MT sender shall either stop transmitting uplink traffic related to the DUCs that are included in the RLC_RESET 
message after sending the RLC_RESET, or transmit dummy PDUs. 

The MT should not start transmitting uplink traffic related to the DUCs that are included in the RLC_RESET message 
before RLC_RESET_ACK is received. If the AP allocates uplink capacity for this particular DUC, the MT shall send 
either the dummy LCH PDU or leave the LCH unused if possible. 

The MT shall reset the ARQ instance immediately after receiving RLC_RESET_ACK. The AP shall reset the ARQ 
instance immediately after receiving RLC_RESET. 

At the reception of RLC_RESET, for the DUCs that are included in the RLC_RESET message, the AP shall: 

• Discard all data in its reception buffer. 

• Set RxBoW to 0. 

• If the receiver is in flow control state, exit the flow control state. 

• Clear all other ARQ state information, i.e. acknowledgement bitmap. 

• Retain all DUC characteristics as agreed upon Setup or latest modification. 

At the reception of RLC_RESET_ACK, for the DUCs that are included in the RLC_RESET message, the MT shall: 

• Optionally discard all data in its transmission buffer (the decision is vendor specific). 

• Set TxBoW to 0. 

• If the sender is in flow control state, exit the flow control state. 

• Clear all other ARQ state information, i.e. rtt awareness for resource requests. 

• Retain all DUC characteristics as agreed upon Setup or latest modification. 

The MT should not transmit a duplicate RLC_RESET message until either the retransmit timer expires or until the 
RLC_RESET_ACK is received. 
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Diagram 66: Mobile originated reset procedure 



MSC Reset_mobile_originated 
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5.3.5 Multicast DUG 

Multicast DUCs are implicitly set up by Group Join during the association procedure, as defined in [5.1.4]. The MAC 
IDs and DLCC IDs reserved for multicast connections are defined in [5]. 

5.3.6 Broadcast DUG 

Broadcast DUCs are implicitly set up by Broadcast Join during the association procedure, as defined in [5.1.5]. The 
MAC IDs and DLCC IDs reserved for broadcast connections are defined in [5]. 

5.3.7 Unicast Direct Link DUG Setup (OAP/OMT) 

The direct link (DiL), which is used in Direct mode (DM), allows direct connections between two or more MTs. The 
corresponding control functions are quite similar to those of the centralized mode (AP/CC and MT). But in this case 
there are one AP/CC and two MTs involved for a DiL unicast connection, as shown as in figure 8. 




MTl 



CTRL 



MT2 



Figure 8: Direct Linit connection between an AP/CC and two lUITs 

The following basic characteristics are valid for the DiL: 

• The access point or central controller shall still control DUC establishment and modification. 

• A calibration mechanism may be used in the control plane, so that: 
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=> Any MT can know which other MTs it has radio contact with 

^> The AP/CC can know the radio map of the network (which MT is in radio contact with which other MT). 

If no means are available to check the connectivity to the peer DM device before DiL DUC Setup, the DiL DUC 
Setup shall be performed anyway. In this case the receiving MT shall monitor whether it is able to receive LCHs 
and/or SCHs of the related DiL DUC. This can be done by monitoring the RG for this DiL DUC. If for a number of 
consecutive RGs for this DiL DUC no LCH and/or SCH has been received successfully the receiving MT shall 
release this DiL DUC by performing the MT initiated DiL DUC release (subclause 5.3.8.2) procedure. The release- 
cause parameter of the RLC_DM_RELEASE message is set to low-qos. The number of consecutive RGs is out of 
the scope of the standard. 

• After receiving the RLC_DM_RELEASE message with release-cause equal to low-qos, the transmitting device may 
initiate a DiL DUC relay Setup (5.3.7.3), in order to establish a DiL DUC to the peer device via the AP/CC. 

The DUC procedures may request several connections, but all these connections shall belong to the same convergence 
layer. 

It may be possible for the higher layers to establish a connection between two MTs (MTl and MT2) even if there is no 
connectivity. In that case, the AP/CC shall act as a Relay by establishing two DiL connections between MTl and AP/CC 
and between AP/CC and MT2. 

The DUC descriptor field contains one direction descriptor for unidirectional or symmetric duplex connections and two 
direction descriptors for asymmetric duplex connections. These direction descriptors are C2i\\&d forward and backward 
descriptor. For unidirectional connection, due-direction field in DUC descriptor shall be set to simplex /orwarc/ for the 
sender and simplex backward for the receiver. If it is set to simplex forward, then only the forward descriptor shall be 
present, and if it is set to simplex backward, then only the backward descriptor shall be present. For symmetric duplex 
connections the due-direction field in DUC descriptor shall be set to symmetric duplex, then the forward and backward 
descriptor would be identical, therefore only the forward descriptor shall be provided. For asymmetric duplex 
connections the forward descriptor is related to the sender and the backward descriptor is related to the receiver. The 
AP/CC is responsible for inverting the contents of the two descriptors for the two MTs involved in the DiL connection. 

All DiL DUC connection control messages shall be transmitted over uplink and downlink DCCH. The MAC ID 
contained in the messages are use to describe the peer MT. 

5.3.7.1 AP/CC initiated DM DUC Setup 

In case of an AP/CC initiated DiL connection set-up, the RLC shall send a RLC_DM_SETUP message, requesting the 
MT to establish one or multiple unicast DUCs. In this message the AP/CC shall indicate to the MT the selected DLCC 
IDs and their connection characteristics (i.e. direction, ARQ parameters, etc.). Referring to the following MSC, iht peer- 
mac-id in the DiL DUC Setup messages from/to MTl shall be set to the MAC ID of the MT2 and the peer-mac-id in the 
DiL DUC Setup messages from/to MT2 shall be set to the MAC ID of the MTl. 

When the AP/CC requires to establish additional DUCs in a subsequent Setup procedure, the AP/CC should indicate this 
by setting the duc-ext-ind flag. The AP/CC shall use the forward direction for the MT that is the sender and the 
backward direction for the receiver MT. 

The MT shall respond with RLC_DM_CONNECT message. The connection characteristics shall not be modified by the 
MT. In order to reject the DiL Setup the MT shall send RLC_DM_RELEASE message and continue with the DiL 
Release procedure. The AP/CC shall send the RLC_DM_CONNECT_ACK message before continuing with the other 
MT. 

The AP/CC shall run the same procedure for the second MT to negotiate the connection. If the second MT can not 
support the characteristics, it shall initiate the DiL Release procedure. 

The AP/CC can also act as one of the MTs, in this case the messages between this MT and the AP/CC are exchanged 
internally in the AP/CC. 
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Diagram 67: Direct Linl< Setup procedure - AP/CC initiated 



MSCDirect_Lmk_Setup_Radio_Connection_AP_initiated 
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Direct_Link_Setup_Radio_Connection_completion 



DUC_established 



The message RLC_DM_CONNECT_COMPLETE shall be used to synchronize the two MTs after the connection phase. 
These messages may be sent in parallel to both MTs. 

If the MT does not receive the RLC_DM_CONNECT_COMPLETE message before the timer runs out, it shall not 
establish the connections and shall initiated the DiL Release procedure. After receiving this message, the MT shall 
respond with RLC_DM_CONNECT_COMPLETE_ACK message. 

In case of the connections use ARQ, the ARQ sequence number of the established DUCs shall be reset to zero in both 
MTs. TxBoW and RxBoW of the corresponding DUCs shall be reset to zero in both MTs. 
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Diagram 68: Completion of direct linl< Setup procedure 
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Table 86: RLC-DIVI-SETUP 



RLC-DM-SETUP-ARG 


:= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE, 


peer-mac-id 


MAC-ID, 


cl-id 


CL-ID, 


duc-ext-ind 


DUC-EXT-IND, 


cl-conn-attr-length 


INTEGER(0..31), 


duc-descr-list 


DUC-DESCR-LIST, 


cl-common-attr 


CL-COMMON-ATTR } 



Table 87: RLC-DI\fl-CONNECT 



RLC-DM-CONNECT-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE, 

peer-mac-id MAC-ID, 

cl-id CL-ID, 

cl-conn-attr-length INTEGER(0..31), 

duc-descr-list DUC-DESCR-LIST } 
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Table 88: RLC-DM-CONNECT-ACK 



RLC-DM-CONNECT-ACK-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE, 

peer-mac-id MAC-ID, 

cl-id CL-ID, 

cl-conn-attr-length INTEGER(0..31), 

dicc-descr-list DLCC-DESCR-LIST } 



Table 89: RLC-DM-CONNECT-COMPLETE 



RLC-DM-CONNECT-COMPLETE-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE, 

peer-mac-id IVIAC-ID, 

dicc-id-list DLCC-DESCR-LIST } 



Table 90: RLC-DM-CONNECT-COMPLETE-ACK 



RLC-DM-CONNECT-CQMPLETE-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-SCH-PDU-TYPE, 

peer-mac-id MAC-ID, 

mac-id MAC-ID } 



NOTE: The AP/CC may be one of the MTs, i.e. MTl or MT2. In this case, the messages shall be sent and 
received internally in the AP/CC. 

5.3.7.2 MI initiated DM DUG Setup 

A MT can also initiate one or several direct link connections by sending the RLC_DM_SETUP message. The MT shall 
make a proposal for the characteristics of the DLC user connections. In that case the DLCC IDs shall be set to zero. 
When the AP/CC receives this RLC_DM_SETUP message from MT, the AP/CC shall respond with 
RLC_DM_CONNECT with DLCC IDs selected by the AP/CC. The AP/CC may modify the connection characteristics. 
If the new characteristics are not acceptable for the initiating MT, it should reject the Setup by initiating a DiL Release 
procedure. 

If the MT has accepted the characteristics in the RLC_DM_CONNECT, the AP/CC shall connect the other MT with the 
same procedure as describe in the AP/CC initiated RLC_DM_ SETUP . 

NOTE: Messages RLC_DM_SETUP, RLC_DM_CONNECT and RLC_DM_CONNECT_ACK are used either in 
uplink and in downlink. 

Once parameters negotiated with the two MTs, the AP/CC shall send the RLC_DM_CONNECT_COMPLETE message 
to both MTs to indicate which of the connections shall be established. Then after receiving these messages, both MTs 
shall respond with RLC_DM_CONNECT_COMPLETE_ACK message. 

The ARQ sequence number of the established DUCs shall be reset to zero in both MTs. TxBoW and RxBoW of the 
corresponding DUCs shall be reset to zero in both MTs. 

Referring to the following MSC, the peer MAC ID in the DiL Due Setup messages from/to MTl shall be set to the MAC 
ID of the MT2 and the peer-mac-id in the DiL Due Setup messages from/to MT2 shall be set to the MAC ID of the 
MTl . If the peer-mac-id is not known to RLC of the initiating MT, then it shall be set to its own value. In that case the 
peer MT is identified in convergence layer container and the AP/CC shall do the mapping. 

The AP/CC can also act as one of the MTs, in this case the messages between this MT and the AP/CC are exchanged 
internally in the AP/CC. 
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Diagram 69: Direct Linl< Setup procedure - MT initiated 



MSC Direct_Lmk_Setup_Radio_Connection_MT_initiated 



DUC_dm_setup_ieq 



(DUC-DM-SETUP-ARG) 



T_dm_setup_mt 



D UC_ d m_c o nnec t_ind 



(DUC-DM-CONNECT-ARG) 
DUC_dm_connect_i>ip 



-DM-CONNECT-ACK-ARG) 
T_dm_co!inect_cmpt_mt 



RLC_DM_SETUP 



([ peer-mac -id, 
ctid, 

duc-ext-ind, 
c 1-c onn-attr-length , 
duc-descr-list, 
clrcommon-attr) ) 



RLC_DM_CONNECT_ACK 



({peer-mac-id, 
cl-id , 

c 1-c o nn-att r-len gth , 
dlcc-descr-list) ) 



DUC_dm_setup_ind 



(DUC-DM-SETUP-ARG) 



DUC_dm_connect_req 



(DUC-DM-CONNECT-ARG) 
T_dm_connect _cmpt_mt \^^ 



T_dm_connect_mt 



DUC_dm_connect_cnf 



CONNECT-ACK-ARG) 



DUC_dm_setup_iid 



(DUC-DM-SETUP-ARG) 

DUC_dm_connec t_req 



RLC_DM_CONNECT 



( { peer-mac -il, 

cl-id, 

c 1-c o nn-attr-lm gth , 

duc-descr-listj) 



(DUC-DM-CONNECT-ARG) 



T_dm_c oniiect_ap 



(DUC-DM-CONNECT-ACK-ARG ) 



DUC_dm_setup_req 



RLC_DM_SETUP 



( { peer-mac -il, 

cUd, 

duc-ext-ind, 

c 1-c o nn-attr-loi gth , 

duc-descr-list, 

cl-common-data)) 



RLC_DM_CONNECT 



(DUC-DM-SETUP-ARG) 



T_dm_setup_ap 



({peer-mac-id, 
cl-id , 

c 1-c onn-attr-length, 
duc-descr-listj ) 



R LC_DM_CONNEC T_ACK 



DUC_dm_connect_ind 



(DUC-DM-CONNECT-ARG) 

DUC_d m_co nnec t_rsp 



(DUC-DM-CONNECT-ACK-ARG 



( { peer-mac -il. 



c 1-c o nn-attr-lai gth , 
dlcc-descr-list)) 



Direc t_Link_Setup_Radio_Co nnec tion_complet ion 



DUC_established 



5.3.7.3 DM DUG Relay Setup 

Even if there is no connectivity between two MTs some facilities might exist for the upper layers to establish a 
connection. In this case, the AP/CC shall relay the data transmission by opening two DiL DUCs for both MTs. The 
RLC_RELAY_SETUP shall be sent by the MT to the AP/CC. The message contains the connection characteristics that 
shall be used by the AP/CC to initiate two DiL Setup procedures. RLC_RELAY_SETUP message shall only be initiated 
by a MT. 
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The AP/CC shall open two direct link DUCs, these connections shall be opened between the MTs and the AP/CC, as 
shown in this figure. In the case MTl has sent the RLC_RELAY_SETUP message, the AP/CC shall respond with the 
RLC_RELAY_SETUP_ACK to MTl. This message shall carry the DLCC_IDs and characteristics of the DUCs opened 
between MTl and the AP/CC. If the negotiated characteristics are not acceptable for the MT, it shall release the 
connection using the RLC_RELAY_RELEASE message. 

Referring to the following MSC, the peer-mac-id of the Relay messages from and to MTl shall be set to the MAC ID of 
the MT2. 

Diagram 70: Relay Setup - MT originated 



MSC Direct_Link_Relay_Setup_Radio_Connection_MT_initiated 



DUCrelaysetupreq 



(DUC -R EL A Y -S ET UP -A RG ) 



RLC_RELAY_SETUP 



Trelaysetupmt 



(I peer-mac-id. 
cUd, 

duc-ext-ind, 
c l-c otin-attr-length, 
duc-descr-list, 
cl-conunon-attr] ) 



DUC_ relay setupiiid 



(DUC-RELAY-SETUP-ARG) 



DirectLitikSetiipRadioCotitiectionAPMT 



I>irect_Lmk_Setup_Radio_Connectbn_AP_MT 



DUCrelaysetuprsp 



RLC_RELAY_SETUP_ACK 



(DUC-RELAY-SETUP-ACK-ARG . 



DUC_rehy_setiip_cnf 



( {peer-mac-id, 

c l-conn-attr-Iengtir, 

dicc-descr-list}) 



(3UC-RELAY-SETUP-ACK-ARG) 



DUC_establislred 



Table 91 : RLC-RELAY-SETUP 



RLC-RELAY-SETUP-ARG ::= SEQUENCE { 


ric-pdu-type 


RLC-LCH-PDU-TYPE, 


peer-mac-id 


MAC-ID, 


cl-id 


CL-ID, 


duc-ext-ind 


DUC-EXT-IND, 


cl-conn-attr-length 


INTEGER(0..31), 


duc-descr-list 


DUC-DESCR-LIST, 


cl-common-attr 


CL-COMMON-ATTR } 



Table 92: RLC-RELAY-SETUP-ACK 



RLC-RELAY-SETUP-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE, 

peer-mac-id MAC-ID, 

cl-conn-attr-length INTEGER(0..31), 

dicc-descr-list DLCC-DESCR-LIST } 
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The connections between the AP/CC and both MTs shall be established by the AP/CC initiated DiL DUC Setup 
procedure, where AP/CC acts as one of the MT. 

The following MSC shows this special case. 

Diagram 71 : Direct Linit Setup connection procedure between AP/CC and lUIT, AP/CC initiated 

MSCDirect_Link_Setup_Radio_Connection_AP_MT 

MT1_ENV I I MT1_RLC 



RLC_DM_SETUP 



DUC_din_setup_ind 



{(DUC-DM-SETUP-ARGI) 



DUCdmconnectieq 



( (peer-mac-id, 

ci-a, 

duc-ext-ind, 

c 1-co nn-attr- length, 

duc-descr-ist, 

cl-common-dataj) 



RLC_DM_CONNECT 



(I DUC-DM-CONNECT-ARG |) 

Tdmconnectcmptmt 



-^ ^y ((peer-mac-id, 

^ cl-id, 

cl-conn-altr- length, 
Tdmco mectint I duc-descr-list 1 ) 



RLC_DM_CONNECT_ACK 



DUC_dm_connect_cnf 



(IDUC-DM-CONNECT-ACK-ARGl) 



{ {peer-mac-id, 

cl-ii, 

cl-co nn-attr- length, 

dlcc-descr-list}) 



RLC_DM_CONNECT_COMPLETE 



DUCdmconncompleteind 



(IDUC-DM-COMPLETE-ARGl) 
DUCdmconncompleteisp 

►- 

(I DUC-DM-COMPLETE-ARG |) 



({ peer-mac-id, 
dice -id-list)) 



RLC_DM_CONNECT_COMPLETE_ACK 



({peer-mac-id }) 



DUCdmsetiipieq 



,. ({DUC-DM-SETUP-ARGD 

Tdmsetupap 



DUCdmconnectind 



({ DUC-DM-CONNECT-ARG]) 

DUCdmconnectrsp 



({DUC-DM-CONNECT-ACK-ARGD 



DUCdmconncompletereq 



({DUC-DM -COMPLETE- ARG|) 



Tdmconnectcmptap 



DUCdmconncompbtecnf 



({ DUC-DM-COMPLETE-ARG ]) 



DUC_estabished 



NOTE: The AP/CC can use AP/CC initiated DiL DUC set up procedure to set up a connection between MTl and 
AP/CC and another one between AP/CC and MT2, then realize the relay between the MTl and MT2. 

5.3.8 Unicast Direct Link DUC Release 
5.3.8.1 AP/CC initiated DM DUC Release 

This procedure is used to release one or more unicast DiL connections in direct mode. 

The AP/CC shall first indicate to a MT to release the indicated DUCs by a RLC_DM_RELEASE message. The MT 
shall send the RLC_DM_RELEASE_ACK to indicate that the relevant DLCC IDs are released. The AP/CC shall not 
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schedule any data to the particular MTs for the particular DLCC IDs after sending the first RLC_DM_RELEASE 

message. 

Referring to the following MSC, the peer-mac -id in the DiL DUC Setup messages from/to MTl shall be set to the MAC 
ID of the MT2 and the peer-mac-id in the DiL DUC Setup messages from/to MT2 shall be set to the MAC ID of the 
MTl. 

The AP/CC shall do the same procedure with the other MT to complete the release of the direct link connections. 

The AP/CC can also act as one of the MTs, in that case the messages between this MT and the AP/CC are exchanged 
internally in the AP/CC. 

Diagram 72: Direct Linit Release connection procedure - AP/CC initiated 



MSC Direct_Link_Release_Radio_Connection_AP_initiated 



MTLENV 




MTLRLC 




MT2_ENV 




MT2_RLC 




AP_RLC 




AP_ENV 





































DUC_established 



DUC_dm_relea.se_ind 






RLC_DM_RELEASE 


RLC_DM_RELEASE_ACK 




( {peer-mac-id, 

dlcc-id-Hst, 

release-cause]) 


( {mac-id. 

peer- mac-id, 

dlcc-a-list, 

release-cause]) 

DUC_dm_ielease_tsp 


(1 mac-id, 
peer-mac-id, 
dice -id-list} ) 


({peer-mac-y, 
dlcc-id-listl ) 


DUC_dm_ielease_ind 


RLC_DM .RELEASE 


( {peer-mac-id, 
dlcc-id-Hst, 

RLC_DM_RELEASE_ACK 


( {mac-id, 

peer-mac-id, 

dbc-id-Itt, 

release-cause]) 

DUC_dm_release_isp 


({mac -id, 
peer-mac-id, 
dlcc-id-list] ) 


({peer-mac-id. 
dfcc-id-lKt] ) 



DUC_dm_release_req 



( {mac-id, 

~7 peer-mac-id, 

^ dlcc-id-list, 

release-cause)) 

T_dm_release_ap 



DUC_dm_release_cnf 



({mac-id, 
peer-mac-id, 
dlcc-id-list) ) 

DUC_dm_release_req 



( {mac -id, 

7 peer-mac-id, 

dlcc-id-list, 

release-cause)) 

T_dm_release_ap 



DUC_dm_release_ctif 



({mac-id, 
peer-mac-id, 
dlcc-id-list) ) 



DUC_ re leased 



Table 93: RLC-DM-RELEASE 



RLC-DM-RELEASE-ARG ::= SEQUENCE { 



ric-pdu-type 
peer-mac-id 
dlcc-id-list 
release-cause 



RLC-LCH-PDU-TYPE, 

MAC-ID, 

DLCC-ID-LIST, 

RELEASE-CAUSE } 
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Table 94: RLC-DM-RELEASE-ACK 



RLC-DM-RELEASE-ACK-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE, 

peer-mac-id MAC-ID, 

dicc-id-list DLCC-ID-LIST} 



5.3.8.2 MT initiated DM DUG Release 

A MT may release one or few DiL connections by sending the RLC_DM_RELEASE message to the AP/CC. When the 
AP/CC receives this message, it shall release the connections with the other MT before sending back the 
acknowledgement. In case that the second MT shall send RLC_DM_RELEASE_ACK as a positive acknowledgement, 
the AP/CC shall send the RLC_DM_RELEASE_ACK to the MT that initiated the Release procedure. 

The AP/CC shall not schedule any data to the particular MTs for particular DLCC IDs after receiving the 
RLC_DM_RELEASE message. 

The AP/CC may also act as one of the MTs, in this case the messages between this MT and the AP/CC are exchanged 
internally in the AP/CC. 
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Diagram 73: Direct Linl< Release connection procedure - IVIT initiated 



MSC Direct_Lmk_Release_Radio_Connection_ 


MT_initated 


















MTI_ 


ENV 




MT1_ 


RLC 




MT2_ 


ENV 




MT2_ 


RLC 




AP_ 


RLC 




AP_ 


ENV 




< 






DUC_established 






\ 








DUC_dm_release_req 
















({mac-id. 














peer-mac-id. 


RLC_DM_RELEASE 


























release-cause |) S 


y 


{{peer-mac-id. 






\ 












dlcc-id-list. 


DUC dm lefease kid 










T_dm_release_mt 




release-cause}) 






({mac-id, 
pea--mac-id. 














dlcc-id-lBt, 
















release-cause j) 






DUC_dm_iBlease_ind 








RLC_DM_RELEASE 


DUC_dm_release_req 




( {mac-id. 








( {peer-mac-id, 
dlcc-id-list. 


\ 


/ peer-mac-id. 


^^ dlcc-id-list, 
release-cause )) 


( |mac-id, 




peer-mac-id. 


















dlcc-id-list, 


















refease-cause)) 


















DUC_dm_release_isp 
















^ 




({mac -id, 


RLC DM RELEASE ACK 
















peer-mac -a, 
dlcc-id-list| ) 










\/ 




({peer-mac-id, 








/ 








die c-id -list 1 ) 








DUC_dm_refcase_cnf 


















([mac-id, 
















peer-mac-id, 
















dlcc-id-lkt) ) 
















DUC_dm_release_rsp 














RLC DM RELEASE ACK 














> 

DUC_dm_refcase_ 


^ 




( {mac-id, 
peer-mac-id, 
dlcc-id-list)) 




({peer_mac-id, 
dlcc-id-listj) 


\ 
cnf 
























( {mac-id. 














peer-mac-id, 














dlcc-id-EstJ) 










/ DUC.released \ 























5.3.8.3 DM DUC Relay Release 

Based on the same principle than in the Relay Setup, the MT shall use the RLC_RELAY_RELEASE message to send 
the DLCC IDs to the AP/CC for the Release. The AP/CC shall release the two direct link connections and sent back the 
RLC_RELAY_RELEASE_ACK message as an acknowledgement to the MT. RLC_RELAY_RELEASE message shall 
only be initiated by a MT. 

The AP/CC shall not schedule any data to the particular MTs for these particular DLCC IDs after receiving the 
RLC_RELAY_RELEASE message. 

Referring to the following MSC, the peer-mac-id of the Relay messages from and to MTl shall be set to the MAC ID of 
the MT2. 
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Diagram 74: Relay Release - MT originated 



MSC Direct_Lmk_Relay_Release_Radio_Connection_MT_initiated 



DUC_rehy_ielease_ieq 

({mac -id, 
peer-mac -id, 
dlcc-id-list, 

release-cause)) 



RLC_RELAY_RELEASE 



4^ I ({pea: 
dlcc- 
release-cause}) 



T_relay_relea.se_mt 



({pei 
dlcc-id-list, 



DUC_relay_ielease_ind 



({mac -id, 
peer-mac -id, 
dlcc-id-list, 
release-cause)) 



Diiect_Link_Release_Radio_Connection_AP_MT 



DiiE:t_Link_Rebase_Radio_Connection_AP_MT 



RL(:_RELAY_RELEASE_ACK 



DUC_relay_release_cnt' 



( (mac-id, 
pea--mac-id, 
dlcc-id-Istj) 



( {peer-mac-id, 
dlcc-id-list)) 



DUC_relay_refease_rsp 



( {mac-id, 
peer-mac-id, 
dtc-id-liitj) 



DUC_ re leased 



Table 95: RLC-RELAY-RELEASE 



RLC-RELAY-RELEASE-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE, 
peer-mac-id MAC-ID, 
dlcc-id-list DLCC-ID-LIST, 
release-cause RELEASE-CAUSE } 



Table 96: RLC-RELAY-RELEASE-ACK 



RLC-RELAY-RELEASE-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE, 
peer-mac-id MAC-ID, 
dlcc-id-list DLCC-ID-LIST} 



The connections between the AP/CC and both MTs shall be released by AP/CC initiated DiL DUC Release, where 
AP/CC acts as one of the MT. 

The following MSC shows this special case. 
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Diagram 75: Direct Linl< Release connection AP/CC - IVIT, AP/CC initiated 



MSC Direct_Lmk_Release_Radio_Connection_AP 


_MT 














MT1_ENV 




MT1_RLC 




AP_ 


RLC 




AP_ENV 
































/ DUC_established 










DUC_dm_relea.se_iiid 


RLC_DM_RELEASE 


DUC_dm_release_req 








( {mac-id, 




( (peer-mac-id, 

dlcc-id-li5t, 

release-cause} ) 

RLC_DM_RELEASE_ACK 


X 


7 peer-mac-id, 


^ dlcc-id-list, 
release-cause}) 
T_dm_release_ap 


( [mac-id, 

peer-mac-id, 

dlcc-id-list, 

release-cause }) 

DUC_dm_ielease_rsp 


({mac-id, 
peer-mac-id, 
dlcc-id-Kst) ) 


({peer-mac-id, 
dlcc-id-list 1 ) 


DUC 


_dm_refease_cnf 






({mac-id, 
peff-mac-id, 
dlcc-id-Isti ) 








/ DUC released 

\ 


/ 



















NOTE: The AP/CC can use AP/CC initiated DiL DUC Release procedure to release connections between MTl 
and AP/CC and between AP/CC and MT2. 

5.3.9 Unicast Direct Link DUC Modify 
5.3.9.1 AP/CC initiated DM DUC Modify 

This procedure shall be used to modify one or multiple unicast DiL connections. 

The AP/CC shall send a RLC_DM_MODIFY_REQ message to one of the two MTs with the new parameters for the 
selected connections. The MT shall accept the modification by sending the RLC_DM_MODIFY, otherwise, if it does 
not accept the modification, it shall start a DiL Release procedure. The MT shall not modify parameters. The AP/CC 
shall respond to the MT with the RLC_DM_MODIFY_ACK as an acknowledgement to indicate, which DLCC IDs are 
concemed by the change. Referring to the following MSC, the peer_mac_id in the DiL DUC Modify messages from and 
to MTl shall be set to the MAC ID of the MT2 and the peer_mac_id in the DiL DUC Modify messages from and to 
MT2 shall be set to the MAC ID of the MTL 

The AP/CC can also act as one of the MTs, in this case the messages between this MT and the AP/CC are exchanged 
internally in the AP/CC. 
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Diagram 76: Direct Linl< l\/lodify procedure - AP/CC initiated 



MSCDirect_Link_Modify_Radio_Connection_AP_initiated 



DUC_Established 



OUp-DM-MODIFY-REQ-ARG ) 
DUC_dm_modify_req 



DUC_dm_modifyreq_ind 



( DUC-DM-MODIFY-ARQ 



modify_cmpt_mt 
T_dm_modify_mt 



( {peer- mac-id, 
cl-conn-attr-length, 

duc-descr-!ist } ) 



DUC_dm_modify_cnf 



niUC-DM-MODIFY-ACK-ARG ) 



F LC_DM_MODIFY_REQ 



RLC_DM_MODIFY 



RLC_DM_MODIFY_ACK 



DUC_dm_modifyreq_ind 



QUC-DM-MODIFY-REQ-ARG ) 
DUC_dm_modify_req 



( DUC-DM-MODIFY-ARQ 

T_dn i_modify_cmpt_mt "x 

T_dm_modify_mt 



DUC_dm_modify_cnf 



QUC-DM-MODIFY-ACK-ARG ) 



( {peer-mac-id, 
cl-conn-attr-length, 
duc-descr-list} ) 



( {peer-mac-id, 
cl-conn-attr-length, 
dlcc-descr-hst} ) 

I^LC_DM_MODIFY_REQ 

( {peer-mac-id, 
cl-conn-attr-length, 
duc-descr-list} ) 



RLC_DM_MODIFY 



( {peer- mac- id, 
cl-conn-attr-length, 

duc-descr-list) ) 



RLC_DM_MODIFY_ACK 



( {peer- mac-id, 
cl-conn-attr-length, 
dlcc-descr-list} ) 



DUC_d m_mod i f yreq_req 



n|UC-DM-M0DIFY-REQ-AR(5 ) 



T_dm_mod i f y_req_ap 



DUC_dm_modify_ind 



( DUC-DM-MODIFY-ARQ 
DUC_dm_mod i f y_r sp 



QUC-DM-MODIFY-ACK-APG ) 



DUC_dm_mod if yreq_req 
DfUC-DM-MODIFY-REQ-ARG ) 



T_dm_modi f y_req_ap 



DUC_dm_modify_ind 

I 

( DUC-DM-MODIFY-ARQ 

DUC_d m_modi f y_r sp 



QUC-DM-MODIFY-ACK-aRG ) 



Direct_Link_Modify_Radio_Connection_completion 



DUC_established 



Table 97: RLC-DM-MODIFY-REQ 



RLC-DM-MODIFY-REQ-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE, 

peer-mac-id MAC-ID, 

cl-conn-attr-length INTEGER(0..31), 

duc-descr-list DUC-DESCR-LIST } 
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Table 98: RLC-DM-MODIFY 



RLC-DM-MODIFY-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE, 

peer-mac-id MAC-ID, 

cl-conn-attr-length INTEGER(0..31), 

duc-descr-list DUC-DESCR-LIST } 



Table 99: RLC-DM-MODIFY-ACK 



RLC-DM-MODIFY-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE, 

peer-mac-id IVIAC-ID, 

cl-conn-attr-lengtii INTEGER(0..31), 

dicc-descr-list DLCC-DESCR-LIST } 



The AP/CC shall use the same procedure to modify parameters of the other MT. For a secure connection, the 
modifications shall be the same for the two MTs. The AP/CC shall send the RLC_DM_MODIFY_COMPLETE 
message to both MTs to indicate that both MTs are able to perform the modifications. The message shall be used to 
synchronize the two MTs after the modification phase. These messages should be sent in parallel to both MTs. 

The MTs shall perform modifications on DUCs after having received the RLC_DM_MODIFY_COMPLETE message 
from the AP/CC, and they shall send the RLC_DM_MODIFY_COMPLETE_ACK message. 
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Diagram 77: Direct Linl< IVIodify connection completion procedure 



MSCDirect_Link_Modify_Radio_Connection_completion 



DJJC-DN^-MODIFY-COMPLETE-ARG ) 
DUC_dm_modify_cmpl_rsp 



T_dm_modify_cmpt_mt 

X — 

DUC_dm_modify_cmpl_ind 



RLC_DV:_MODIFY_COMPLETE 



l-MODIFY-COMPLETE-ACK-ARQ! 

RLC_DM_MODIFY_COMPLETE_ACK 



( {peer-mac-id}) 



T_dm_modify_cmpt_mt 



DUC_d in_mod i f y_cmpl_ind 



D(U(:-DM-MODIFY-COMPLETE-ARG ) 



DUC_dm_modif y_c mp l_r sp 



( DUC-DM-MODIFY-COMPLETE-ACK-ARQ 



DUC_dm_modify_cinpl_req 



((peer-mac-id, 
dlcc-id-list} ) 



Duc-dm-modify-complet: 

T_dm_mod if y_cmpt_ap 



DUC_dm_modif y_c mp l_cnf 



( DUC-I)M-MODIFY-COMPLETE-ACK 

DUC_dm_modify_cmpl_req 



RLC_DV _MODIFY_COMPLETE 



{{peer-mac-id, 
dlcc-id-list} ) 



^UC-DM-MODIFY-COMPLETE-ARG ) 
T_dm_modify_cmpt_ap 



RLC_DM_MODIFY_COMPLETlE_ACK 



( {peer-mac-id}) 



DUC_dm_modify_cmpI_cnf 



( DUC-DVI-MODIFY-COMPLETE-ACK- 



;-ARG ) 



-ARO 



ARO 



Table 100: RLC-DI\fl-MODIFY-COIVIPLETE 



RLC-DM-MODIFY-COMPLETE-ARG ::= SEQUENCE { 



ric-pdu-type 
peer-mac-id 
dlcc-id-list 



RLC-LCH-PDU-TYPE, 

MAC-ID, 

DLCC-ID-LIST} 



Table 101 : RLC-DI\fl-MODIFY-COI\flPLETE-ACK 



RLC-DM-MODIFY-COMPLETE-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-SCH-PDU-TYPE, 

peer-mac-id MAC-ID, 

mac-id MAC-ID } 



NOTE: The AP/CC may be one of the MTs, i.e. MTl or MT2. In this case, the messages shall be sent and 
received internally in the AP/CC. 

5.3.9.2 MT initiated DM DUG Modify 

A MT shall initiate a DUG Modify by sending the RLC_DM_MODIFY_REQ message to the AP/CC. This message 
shall contain the new parameters proposed for the modification of one or more connections. The AP/CC shall use the 
RLC_DM_MODIFY message to modify parameters if it is not able to accept those that are proposed. If the MT accepts 
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the parameters in the RLC_DM_MODIFY message, the MT shall accept it by sending the RLC_DM_MODIFY_ACK 
message with accepted DLCC IDs. Both MT and AP/CC may reject modifications required by initiating the DiL Release 
procedure. 

The AP/CC shall use the same procedure to modify the parameters of the other MT involved in this direct link. 

Referring to the following MSC, the peer MAC ID in the DiL Due Setup messages from/to MTl shall be set to the MAC 
ID of the MT2 and the peer MAC ID in the DiL Due Setup messages from/to MT2 shall be set to the MAC ID of the 
MTL If the peer MAC ID is not known to RLC of the initiating MT, then it shall be set to its own value. In that case the 
peer MT is identified in convergence layer container and the AP/CC shall do the mapping. 

The AP/CC can also act as one of the MTs, in this case the messages between this MT and the AP/CC are exchanged 
internally in the AP/CC. 
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Diagram 78: Direct Linl< IVIodify procedure - IVIT initiated 



MSC Direct_Link_Modify_Radio_Connection_MT_initiated 



MTLENV 




MTLRCP 




MT2_ENV 




MT2_RCP 




AP_RCP 




AP_ENV 





































(D JC-DM-MODIFY-REQ-ARG) 



(DUC-DM-MODIFY-ACK-ARG) 



Tdmmodifycmptmt 



DUG _dm_modifyreq_iEq 



X 



T_ d ni _ 111 od if y_ re q_ m t 



DUC_dm_modify_ind 



(DUC-DM-MODIFY-ARG) 
D UC _ d m_ m o d if y_ r^ p 



RLC_DM_MODIFY_REQ 



(Ipeer-mac-id, 
cl-c on n-attr- length, 
due -descr-list) ) 



RLC_DM_MODIFY_ACK 



({peer-mac-id. 
c 1- c o n n- attr- le ng th, 
dlcc-descr-list } ) 



D UC _ d m_ ni o d ify re q_ ind 



-DM-MODIFY-REQ-ARG) 

DUC_ d ni_mo d ify_ leq 



(DUC-DM-MODIFY-ARG) 
odify_cnipt_mt 



T_dm_modify_mt 



^ 



DUC_dm_modify_cnr^ 



(DUC-DM-MODIFY-ACK-ARG) 



RLC_DM_MODIFY 



( { peer-mac -id, 

c 1-c o nn-attr-length , 

duc-descr-list ]) 



RLC_DM_MODIFY_REQ 



( { peer-mac -id, 

c 1-c o nn-attr-length , 

duc-descr-list ]) 



RLC_DM_MODIFY 



({ peer-mac-id. 
c 1-conn-attr-length, 
duc-descr-list] ) 



RLC_DM_MODIFY_ACK 



( {peer-mac-id. 

c 1-c o nn-attr-length . 

dlcc-descr-list ]) 



DUC_dm_modfyieq_ind 



(DUC-DM-MODIFY-REQ-ARG) 
DUC_dni_modify_req 



(DUC-DM-MODIFY-ARG) 



T_dm_modify_ap 



DUC_dm_modify_cnf 



(DUC-DM-MODIFY-ACK-ARG) 
DUC _d ni_niod ifyreq_req 



(DUC-DM-MODIFY-REQ-ARG) 



T_dm_inodify_req_ap 



DUC_dm_niodify_ind 



(DUC-DM-MODIFY-ARG) 

DUC_dm_modify_rsp 



(DUC-DM-MODIFY-ACK-ARG) 



Direc t_Link_Modify_Radio_Connection_completion 



DUC_ established 



After receiving RLC_DM_M0D1FY_ACK the AP/CC shall send the RLC_DM_MODIFY_COMPLETE message to 
synchronize both MTs and also to indicate, which connections will change their characteristics. If both MTs do not 
accept the same parameters, the AP/CC shall release the connections. Then after receiving these messages, both MTs 
shall respond with RLC_DM_CONNECT_COMPLETE_ACK message. 
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5.3.9.3 DM DUG Relay Modify 

The principle of this procedure is the same than in the Relay Setup, the MT will ask the AP/CC to modify the two direct 
link connections previously opened between AP/CC and MTl, and between MT2 and AP/CC. The DLCC IDs used shall 
be those of the connections between the AP/CC and the MT that sent the RLC_DM_RELAY_MODIFY message. The 
AP/CC shall respond with the RLC_RELAY_MODIFY_ACK containing the modified DLCCJDs as an 
acknowledgement. This list shall be empty, if the AP/CC or the other MT have not accepted the requested 
characteristics. 

RLC_RELAY_MODIFY message shall only be initiated by a MT. Referring to the following MSC, the peer-mac -id of 
the Relay messages from and to MTl shall be set to the MAC ID of the MT2. 

Diagram 79: Direct Linl< Relay IVIodify procedure - IVIT initiated 



MSC Direct_Link_Relay_Modify_Radio_Connection_MT_initiated 



DUC_relay_mod ify_req 


(Imir-a. 


peer-mac -a, ^ 


-7 


cl-conn- attr-length, /- 
duc-descr-lKt] ) 

T_reky_modify_mt 





RLC_RELAY_MODIFY 


DUC_relay_modify_ind 










({peer-mac-id, 
cl-conn-attr-leiigth, 








" 




duc-descr-list) ) 


([mac -id, 
peer-mac -id, 
cl-conn -attr-length, 
duc-descr-list) ) 











Direct_Link_Modrfy_Radio_Connection_AP_MT 



Direct_Link_Modify_Radio_Connection_AP_MT 



RLC_RELAY_MODIFY_ACK 



DUC_relay_modify_cnf 



( [peo^-mac-id, 

cl-conn -attr-length, 

dbc-descr-I^t )) 



^ [mac-id, 

pea^-mac-id, 

cl-conn-attr- length, 

dlcc-descr-list ]) 



DU C_ie la y_ modify _tsp 



[mac-id, 

peer-mac-id, 

c irc o nn-attr- length , 

dlcc-descr-list)) 



DUC .modified 



Table 102: RLC-RELAY-MODIFY 



RLC-RELAY-MODIFY-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE, 

peer-mac-id MAC-ID, 

cl-conn-attr-length INTEGER(0..31), 

duc-descr-list DUC-DESCR-LIST } 
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Table 103: RLC-RELAY-MODIFY-ACK 



RLC-RELAY-MODIFY-ACK-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE, 

peer-mac-id MAC-ID, 

cl-conn-attr-length INTEGER(0..31), 

dicc-descr-list DLCC-DESCR-LIST } 



The connections between the AP/CC and both MTs shall be modified by AP/CC initiated DiL DUC Modify procedure, 
where AP/CC acts as one of the MT. 

The following MSC shows this special case. 

Diagram 80: Direct Linit IVIodify connection AP/CC - IVIT, AP/CC initiated 

MSC Direct_Link_Modify_Radio_Connection_AP_MT 



DUC„Established 



(DL 



RLC_DM_MODIFY_REQ 



DUC _dm_ mo d ifyreq iiid 



(DUC-DM-MODIFY-REQ-ARG) 
DUCdmmodifyieq 



( { peer-mac -id, 

c 1-co nn-attr-length , 

duc-descr-list ]) 



RLC_DM_MODIFY 



"Xr 



(DUC-DM-MODFY-ARG) 

T_dm_modify_cmpt_mt 

T_dm_i]iodify_mt 



DUC_dm_modify_ciif 



(DUC-DM-MODFY-ACK-ARG) 



V7 {[peer-mac-id 

^r^ Cl-C O ■ 



nn-attr-length, 
duc-descr-list] ) 



RLC_DM_MODIFY_ACK 



( [peer-mac -id, 

c 1-co nn-att r-len gth , 

dicc-descr-list ]) 

RLC_DM_MODIFY_COMPLETE 



DUC_dni_modify_cmpl_ind 



([ peer-mac -id, 
dice -id-list)) 



(DUC-DM-MODIFY-COMPLETE-ARG) 



DUC_dm_modify_cmpl_rsp 



RLC_DM_MODIFY_COMPLETE_ACK 



C-DM-MODIFY-COMPLETE-ACK-ARG) 



({ peer-mac-id ]) 



DUC _d m_niod ifyreq_req 



(DUC-DM-MODIFY-REQ-ARG) 
T_dm_modify_req_ap 



-^ DUC_dm_modify_hd 



(DUC-DM-MODIFY-ARG) 

DUC_ d m_ mod ify_ rsp 



([DUC-DM-MODIFY-ACK-ARG]) 
DUC _d ni _ nio d if y_ c ni p 1_ leq 



(DUC-DM-MODIFY-COMPLETE-ARG) 



-^ 



T_dm_modify_cmpt_i^ 



D UC_ d ni_ m o dif y_ c nip 1_ c nf 



(DUC-DM-MODFY-COMPLETE-ACK-ARG) 



DUC_established 
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5.3.1 Unicast Direct Link DUG Reset 

With the reset procedure the ARQ instance and related timers of one or more unicast DiL DUCs shall be reset to their 
initial state. The DUC characteristics as agreed on Setup or latest modifications will be maintained. The direct link Reset 
procedure shall be initiated by sending the RLC_DM_RESET message including the DLCC ID(s) of the DUCs. The 
receiving entity (MT and/or AP/CC) shall acknowledge the Reset by responding with RLC_DM_RESET_ACK 
indicating the corresponding DLCC ID(s). 

NOTE: These messages may not be used for connections using FCA or FSA. 

5.3.10.1 AP/CC initiated DM DUC Reset 

This procedure allows to reset one or more unicast DiL connections. The AP/CC should stop scheduling data to the 
particular MT after sending the RLC_DM_RESET message. 

To reset the DUCs in the MT, the AP/CC shall send the RLC_DM_RESET message. The MT shall send the 
RLC_DM_RESET_ACK as positive acknowledgement, if the relevant DLCC_ID has been reseted. 

The AP/CC shall do the same procedure with the other MT to complete the Reset of the direct mode connections. 
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Diagram 81 : Direct Linl< Release connection procedure - AP/CC initiated 



MSC Direcl_Link_Reset_Radio_Connection_AP_initated 



DUC_esIablished 









RLC DM RESET 


DUC„dm_reseI_req 








DUC_^dm„reseI_ind 




( {mac-id, 


({peer-mac-id, 
dlcc-id-BsIi) 




7 peer-mac-id. 


^ dlcc-id-listj) 








( (mac-id. 












peer-mac-id. 












dtc-id-lGt)) 






T_dm_resa_ap 






DUG dm reset cnf 














RLC_DM_RESET_ACK 




< 


({mac -id, 
peer-mac-id. 


({peer-mac-id, 


/ 






dfcc-id-list} ) 


dfcc-id-lkt) ) 


DUC_dm_reseI_cnf 












({mac-id. 










peCT-mac-id, 










dlCC-id-lKt| ) 








RLC DM RESET 


DUC_dm_reset_req 


^ 


DUC_dm_ieset_ind 








( {mac-id. 






({pear-mac-id, 
dlcc-id-list)) 




/ peer-mac-id. 


^ 


^ dlcc-id-lisli) 


^ 


( (mac-id, 
peer-mac-id, 










T_dm_resel_ap 


dlcc-id-Ust)) 












DUC_dm_ieset_rsp 


RLC DM RESET ACK 












(Imac-il, 












peer-mac-id, 
dlcc-id-list) ) 










\ 


(Ipeer-mac-id, 










dlcc-id-Esti ) 






DUC_dm_reset_cnf 












({mac-id, 










pea--mac-id, 










dlcc-id-Ist| ) 



DUC_esIablished 



Table 104: RLC-DIVI-RESET 



RLC-RESET-ARG ::= SEQUENCE { 



ric-pdu-type RLC-LCH-PDU-TYPE, 

peer-mac-id MAC-ID, 

dlcc-id-list DLCC-ID-LIST} 



Table 105: RLC-DI\fl-RESET-ACK 



RLC-RESET-ACK-ARG ::= SEQUENCE { 



rIc-pdu-type RLC-LCH-PDU-TYPE, 

peer-mac-id MAC-ID, 

dlcc-id-list DLCC-ID-LIST} 
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5.3.1 0.2 MT initiated DM DUG Reset 

A MT shall use the RLC_DM_RESET message to reset a connection. When the AP/CC receives this message, it shall 
reset the connection with the other MT before sending back the RLC_DM_RESET_ACK. In case the second MT sends 
the RLC_DM_RESET_ACK as a positive acknowledgement, the AP/CC shall acknowledge to the MT that has initiated 
the reset procedure. 

The AP/CC shall reset the ARQ instance just after receiving RLC_DM_RESET message. TxBoW and RxBoW of the 
corresponding DUCs shall be reset to zero both in the MT and the AP/CC. 

Diagram 82: Direct Linit Release connection procedure - IVIT initiated 



MSC Direct_Mode_Reset_Radio_Connection_MT_initated 


















MT1_ENV 




MT1_RLC 




MT2_ENV 




MT2_RLC 




AP_RLC 




AP_ENV 












































/ DUC.established \ 








DUC_dm_resel_ind 




DUC_dm_reset_req 


RLC_DM_RESET 


DUC_dm_ieset_ind 








({mac-id, 

peer-mac-id, \7 
dlcc-id-list} ) ^^ 




(Ipeer-mac-id. 
dlcc-id-list) ) 

RLC_DM_RESET 


T_dm_reset_mt 




((mac-id. 
peer-mac-id, 
dlcc-id-Etl ) 

DUC_dm_reset_req 


( (mac-id, 


RLC_DM_RESET_ACK 






((peer-mac-id, 
dlcc-id-list 1) 




7 peer-mac-id. 


\ 


^ dlcc-id-list 1) 
T_dm_reset_ap 

/ 


( [mac -id, 

peer-mac-id, 
dlcc-id-list|) 

DUC_dm_reset_rsp 


((mac-ki, 
peer-mac -id, 
dlcc-id-Ust| ) 


([peer-mac-id, 
dlcc-id-ist| ) 




RLC_DM_RESET_ACK 


DUC_dm_resel_ 


cnf 


/ 
DUC 


\ 

_dm_rese t_cnf 


((mac-id, 
peer-mac-id, 
dlcc-id-Etl ) 


( {peer-irrac-id, 
dlcc-id-list 1) 






{ 1 mac-id. 
peer-mac-id, 
dlcc-id-lMl) 








/ \ 
/ DUC_established \ 























5.3. 11 Multicast Direct Link 

Multicast DUCs are implicitly set up by Group Join procedure after the Association procedure, as defined in 5.3. 11 . The 
MAC IDs and DLCC IDs reserved for multicast connections are defined in [5]. 

5.3.12 Broadcast Direct Link 

Broadcast DUCs are implicitly set up by Broadcast Join during the association procedure, as defined in subclause 5.1.5. 
The MAC IDs and DLCC IDs reserved for broadcast connections are defined in [5]. 
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6 Timers and repetitions of RLC messages 

RLC messages use DLC unacknowledged mode and they use the most robust PHY mode. Retransmission at the RLC 
level shall be used to ensure the receiving of the messages. When a message is sent, a timer function shall be activated at 
the sender. If a reply to the sent message is not received within the time set for the timer function, the sender of the 
message shall send the message again (retransmit). The maximum number of retransmissions shall be 4, that is, the 
maximum number of transmissions shall be 5. The receiver of the message that is sent by the sender, shall respond 
within the time set for the timer function at the sender. The exception for this scheme are the unacknowledged broadcast 
messages (e.g. RLC_CHANGE_FREQUENCY), which may be sent more often and without specific limits in 
retransmission timers. 

The timer values differ within wide ranges, both for implementation reasons and, for certain messages, due to delays in 
the fixed network. A message should not be retransmitted until the timer function has expired. For the case of large timer 
function values, this would mean that retransmission could take a long time (the number of retransmissions times the 
timer value). To avoid that to happen, the timer function shall work as follows. For all timer values, an ordinary timer 
shall be started at the sending of a message, supervising the arrival of the ordinary acknowledgement to the sent 
message. For long and medium timer values, an extra timer (short timer value) may be started. The function of the extra 
timer shall be to supervise the retransmission procedure of the sender. A reply message, RLC_PROCEEDING, shall be 
used as acknowledgement and to stop the extra (short) timer. The total retransmission time is then the number of 
retransmissions times the short time instead of the number of retransmission times the medium or long time. 

The use of the extra timer should be used for time critical functions like association/handover. 

The RLC_PROCEEDING message with the short extra timer shall also be used when a message has no answer to secure 
that messages will be retransmitted when needed. 
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Diagram 83: Repetition and proceeding procedure 



MSC Repeting_signals 



Sigial_ieady 



S igral_A_req 



S ignal_A_ind 



T_long_or_medium 



T_short ^- 



SIGNAL_A_ACK 



X- 



({challenge- to-mtj) 



S ignal_A_rsp 



Sigml_A_req 



T_long_or_midium ^^ 



Signal_A_req 



T_long_or_medium N^ 



^ 



'_slKrt2<— 



SignalAind 



RIjC_PROCEEDING 



S1GNAL_A_ACK 



SIGNAL_A_ACK 



Signal Arsp 



Si§ial_transmitEd 



Table 106: RLC-PROCEEDING 



RLC-PROCEEDING-ARG ::= SEQUENCE 



ric-pdu-type RLC-SCH-PDU-TYPE, 

sch-lch SCH-LCH, 

no-support-pdu-type PDU-TYPE-CHOICE, 
extension-type EXTENSION-TYPE, 

mac-id MAC -ID } 
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7 PDU for unsupported messages 

The RLC TS contains several optional functions and there may be new versions and extensions in future. Therefore, 
there is no confirmation that both the MT and AP support all the messages they receive. In the case that the MT or the 
AP receives an RLC message that it does not support, it shall send the RLC_NO_SUPPORT message. 

Table 107: RLC-NO-SUPPORT 



RLC-NO-SUPPORT-ARG ::= SEQUENCE 



ric-pdu-type RLC-SCH-PDU-TYPE, 

sch-lch SCH-LCH, 

no-support-pdu-type PDU-TYPE-CHOICE, 
extension-type EXTENSION-TYPE, 

mac-id MAC -ID } 



8 Primitives 

8.1 Primitive types 

Four primitive types may be used: 

-req (request), for a higher layer to request service from a lower layer; 

-cnf (confirm), for the layer providing the service to confirm that the activity has been completed; 

-ind (indication), for a layer providing a service to notify the next higher layer of any specific service related activity; 

-rsp (response), for a layer to acknowledge receipt of an indication primitive from the next lower layer. 

The defined types for each category of primitive are shown as a list in curly brackets. 

NOTE: These primitives are defined only for the purpose of describing layer-to-layer interactions. The primitives 
are defined as an abstract list of parameters, and their concrete realization may vary between 
implementations. No formal testing of primitives is intended. The following primitive definitions have no 
normative significance. 

8.2 Primitives to the Convergence Layer, DLC C-SAP 

This subclause summarizes the primitives between the convergence layer and the RLC layer. 
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Convergence Layer 



DLC C-SAP 
Primitives 




PLC Primitives 



RLC protocol 



The primitives at the DLC C-SAP have a correspondence to a subset of the RLC primitives defined in section xx. The 
parameters used in the primitives at the DLC C-SAP are equal to or a subset of the RLC parameters defined in section 

XX. 

At the AP the MAC ID is used to distinguish between different RLC instances. In the MT only one RLC instance exist. 
The following DLC C-SAP primitives with their corresponding RLC primitives exist: 



DLC C-SAP primitive 


RLC primitive 


DLC_SETUP -{req, ind}; 


DUC SETUP - { req, ind }; 
DM SETUP - { req, ind }; 


DLC_CONNECT - { req, cnf, ind, rsp }; 


DUC CONN - { req, cnf, ind, rsp }; 
DM CONN - { req, cnf, ind, rsp }; 


DLC_RELEASE - { req, cnf, ind, rsp }; 


DUC_RELEASE - { req, cnf, ind, rsp }; 
DM RELEASE - { req, cnf, ind, rsp }; 


DLC_MODIFY - { req, cnf, ind, rsp }; 


DUC MODIFY - { req, cnf, ind, rsp }; 
DM MODIFY - { req, cnf, ind, rsp }; 


DLC MULTICAST JOIN - { req, cnf, ind, rsp }; 


ACF GROUP JOIN - { req, cnf, ind, rsp }; 


DLC MULTICAST LEAVE - { req, ind }; 


ACF GROUP LEAVE - { req, cnf, ind, rsp }; 


DLC CL BROADCAST JOIN - { req, cnf, ind, rsp }; 


ACF CL BROADCAST JOIN - {req, cnf, ind, rsp}; 


DLC INFO TRANSFER - { req, cnf, ind, rsp }; 


ACF INFO - { req, cnf, ind, rsp }; 



NOTE: One DLC C-SAP primitive may correspond to one of possibly several RLC primitives. It is the task of the 
RLC functions (ACF and DCC) to control the relation between DLC C-SAP primitives and the RLC 
primitves. The RLC functions invoke the RLC primitives with appropriate parameters. (E.g. a request 
from the CL to setup 8 connections may result in 2 subsequent connection setup sequences at the RLC 
level, each setting up 4 connections). 
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Annex A (normative): 

PDU type and Transfer Syntax Tables 

A.1 RLC PDU type 

The MT and AP columns indicate, whether the PDU is Mandatory or Optional to implement in the MT and AP for the 
basic RLC Technical Specification. The PDU can be mandatory for both the sender and the receiver or the other peer 
only. If a PDU is mandatory for the sender, the sender shall be able to encode the PDU and send it at the correct time 
according to RLC TS. If the PDU is mandatory for the receiver, it shall be able to decode the PDU and perform the 
requested actions according to RLC TS. If the PDU is optional, the sender may not be able to encode or use it. If the 
PDU is optional the receiver may not be able to decode the PDU, but the receiver shall be able send corresponding 
RLC_NO_SUPPORT message. 

A.1.1 LCH RLC PDU type 

Table A.I : RLC ACF LCH PDU messages: 











(0000 0001)1 


RLC RBCH ASSOCIATION 


M 


M 


2 


RLC LINK CAPABILITY 


M 


M 


3 


RLC LINK CAPABILITY ACK 


M 


M 


4 


RLC KEY EXCHANGE MT 1 


M 


M 


5 


RLC KEY EXCHANGE MT 2 


M 


M 


6 


RLC KEY EXCHANGE AP 1 


M 


M 


7 


RLC KEY EXCHANGE AP 2 


M 


M 


8 


RLC AUTHENTICATION 


M 


M 


9 


RLC AUTHENTICATION MT 


M 


M 


10 


RLC AUTHENTICATION AP 1 


M 


M 


11 


RLC AUTHENTICATION AP 2 


M 


M 


12 


RLC AUTHENTICATION AP 3 


M 


M 


13 


RLC AUTHENTICATION ACK 1 


M 


M 


14 


RLC AUTHENTICATION ACK 2 


M 


M 


15 


RLC AUTHENTICATION ACK 3 


M 


M 


16 


RLC DM COMMON KEY DISTR 








17 


RLC DM COMMON KEY DISTR ACK 








18 


RLC INFO 








19 


RLC INFO ACK 








20 


RLC UNICAST KEY REFRESH 


M 





21 


RLC UNICAST KEY REFRESH ACK 


M 





22 


RLC COMMON KEY REFRESH 


M 





23 


RLC COMMON KEY REFRESH ACK 


M 





24 


RLC GROUP JOIN 








25 


RLC GROUP JOIN ACK 








26 


RLC GROUP JOIN NACK 








27 


RLC GROUP LEAVE 








28 


RLC GROUP LEAVE ACK 








29 


RLC CL BROADCAST JOIN 








30 


RLC CL BROADCAST JOIN ACK 








31 


RLC CL BROADCAST LEAVE 








32 


RLC CL BROADCAST LEAVE ACK 
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Table A.2: RLC RRC LCH PDU messages: 











64 


RLC RADIO HANDOVER COMPLETE 








65 


RLC HANDOVER ASSOCIATION 








66 


RLC HANDOVER LINK CAPABILITY ACK 








67 


RLC NW SIGNALLING HANDOVER 








68 


RLC NW SIGNALLING HANDOVER ACK 








69 


RLC NETWORK HANDOVER COMPLETE 








70 


RLC HO INFO DISTRIBUTION 








71 


RLC DPS MEASUREMENT COMPLETE REQUEST 


M 


M 


72 


RLC DPS MEASUREMENT PERCENTILES REQUEST 


M 


M 


73 


RLC DPS MEASUREMENT SHORT REQUEST 


M 


M 


74 


RLC DPS REPORT COMPLETE 


M 


M 


75 


RLC DPS REPORT PERCENTILES 


M 


M 


76 


RLC DPS REPORT SHORT 


M 


M 



Table A.3: RLC DUCC LCH PDU messages: 











128 


RLC SETUP 


M 


M 


129 


RLC CONNECT 


M 


M 


130 


RLC CONNECT ACK 


M 


M 


131 


RLC RELEASE 


M 


M 


132 


RLC RELEASE ACK 


M 


M 


133 


RLC MODIPY REQ 








134 


RLC MODIPY 








135 


RLC MODIPY ACK 








136 


RLC RESET 


M 


M 


137 


RLC RESET ACK 


M 


M 


138 


RLC DM SETUP 








139 


RLC DM CONNECT 








140 


RLC DM CONNECT ACK 








141 


RLC DM CONNECT COMPLETE 








143 


RLC DM RELAY SETUP 








144 


RLC DM RELAY SETUP ACK 








145 


RLC DM MODIPY REQ 








146 


RLC DM MODIPY 








147 


RLC DM MODIPY ACK 








148 


RLC DM MODIPY COMPLETE 








149 


RLC DM RELAY MODIPY 








150 


RLC DM RELAY MODIPY ACK 








151 


RLC DM RELEASE 








152 


RLC DM RELEASE ACK 








153 


RLC DM RELAY RELEASE 








154 


RLC DM RELAY RELEASE ACK 








155 


RLC DM RESET 








156 


RLC DM RESET ACK 









A.1.2 SCH RLC PDU type 

Table A.4: RLC ACF SCH PDU messages: 











(0000 0001) 1 


RLC RBCH ASSOCIATION REQ 





M 


2 


RLC MAC ID ASSIGN 


M 


M 


3 


RLC MAC ID ASSIGN ACK 


M 


M 


4 


RLC MAC ID ASSIGN NACK 


M 


M 


5 


RLC COMMON KEY ACTIVATE 


M 





6 


RLC DISASSOCIATION 


M 


M 


7 


RLC DISASSOCIATION ACK 


M 


M 


8 


RLC PROCEEDING 


M 


M 
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Table A.5: RLC RRC SCH PDU messages: 











64 


RLC SECTOR HANDOVER REOUEST 








65 


RLC SECTOR HANDOVER ACK 








66 


RLC HANDOVER NOTIFY 








67 


RLC HANDOVER REOUEST 








68 


RLC HANDOVER REOUEST NACK 








70 


RLC HO INFO DISTRIBUTION ACK 








71 


RLC FORCE HANDOVER 








72 


RLC FORCE HANDOVER ACK 








73 


RLC AP ABSENCE 


M 





74 


RLC MT INIT REPORT REQUEST 








75 


RLC MT INIT REPORT REQUEST ACK 








76 


RLC CHANGE FREQUENCY 


M 


M 


77 


RLC UPLINK PC CALIBRATION 


M 


M 


78 


RLC MT ALIVE REQUEST 


M 


M 


79 


RLC MT ALIVE REQUEST ACK 


M 


M 


80 


RLC MT ALIVE 


M 


M 


81 


RLC MT ALIVE ACK 


M 


M 


82 


RLC MT ABSENCE 








83 


RLC MT ABSENCE ACK 








84 


RLC SLEEP 





M 


85 


RLC SLEEP ACK 





M 



Table A.6: RLC DUCC SCH PDU messages: 











128 


RLC DM CONNECT COMPLETE ACK 








129 


RLC DM MODIFY COMPLETE ACK 


Q 


Q 



Table A.7: OTHER RLC SCH PDU messages: 











255 


RLC NO SUPPORT 


M 


M 



A.2 Transfer Syntax Tables for LCH ACF messages 
A.2.1 RLC-RBCH-ASSOCIATION encoding 





8|7|6|5|4|3|2| 1 


Octet 4 


NQP-ID Length (=L) 


Octet 5 


IDENTIFIER-FORMAT | Unique Length (=UL) 


Octet 6 


Future use C-U-G 


Octet 7 


H2 Network Operator Identifier string - local part 




H2 Network Operator Identifier string - globally unique part 




Not used (depends on L) 


Octet 40 


Future use # of CLs in list (N) 


Octet 41 


#1 CL-ID 


Octet 42 


#1 CL-VERSION 








#N CL-ID 


Octet 40+2xN 


#N CL-VERSION 




Not used 




Octet 51 
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A.2.2 RLC-LINK-CAPABILITY encoding 





8|7|6|5|4|3|2|1 


Octet 4 


DLC version 


Octet 5 


RLC version 


Octet 6 


Future use | #CL_VID(N) 


Octet 7 


CL-ID-1 


Octet 8 


CL version-1 




Other CL-ID and CL_Version 


Octet 7+(2*N) 


Freq-band-MT 


RSS value 


Octet 


64QAI\/I? 1 DIVI-cap 


Cyclic 


FCA? 


FSA? 


Time-gap-ACH-UL 


Octet 


Future use 


ho-cap 


cc-ho-cap 


Future use 


Duty-cycle 


Octet 


ARQ-DELAY-rx 


ARQ-DELAY-tx 


Auth/Encr-No-of-Proposals (K) 


Octet 


Authentication-Proposal-*! 


Encryption-Proposal-#1 


Octet 


Authentication-Proposal-#2 


Encryption-Proposal-#2 




Possibly used for up to 15 proposals (for one CL) 






11+(2*N)+K 


DIL-power-control | TX-ARQ-WIN-SIZE | RX-ARO-WIN-SIZE 




Not used (size depends on #CL_VID, DM-cap, #of proposals) 




Octet 51 













A.2.3 RLC-LINK-CAPABILITY-ACK encoding 





8|7|6|5|4|3|2|1 


Octet 4 


DLC-VERSION 


Octet 5 


RLC version 


Octet 6 


Freq-band-sel RSS-value 


Octet 7 


APT-ADDRESS-LENGTH 


640AM 1 DMCkey 


DM-cap Cyclic 


Octet 8 


FCA FSA Future cc-ho-cap 


ARQ-DELAY-rx 


ARQ-DELAY-tx 


Octet 9 


Authentication-Selected 


Encryption-Selected 


Octet 1 1 


DIL-power-control | OUT-ARQ-WIN-SIZE | IN-ARO-WIN-SIZE 


Octet 12 


Not used 


Octet ... 


Octet 51 









A.2.4 RLC-KEY-EXCHANGE-IVIT-I encoding 





8 


7 


6 1 5 1 4 1 3 


2 


1 


Octet 4 


MT_DH_PUBLIC_VALUE_PART1 




Octet 51 



A.2.5 RLC-KEY-EXCHANGE-l\/IT-2 encoding 





8 


7 


6 1 5 1 4 1 3 


2 


1 


Octet 4 


MT_DH_PUBLIC_VALUE_PART2 




Octet 51 
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A.2.6 RLC-KEY-EXCHANGE-AP-1 encoding 





8 


7 


6 1 5 1 4 1 3 


2 


1 


Octet 4 


AP_DH_PUBLIC_VALUE_PART1 




Octet 51 



A.2.7 RLC-KEY-EXCHANGE-AP-2 encoding 





8 


7 


6 1 5 1 4 1 3 


2 


1 


Octet 4 


AP_DH_PUBLIC_VALUE_PART2 




Octet 51 



A.2.8 RLC-AUTHENTICATION encoding 





8 


7 


6 


1 5 1 4 1 3 1 2 1 


1 


Octet 4 


More 


Future use 


Length of MT-AUTH-ID in this PDU (L) 


Octet 5 




Future use 


1 MT-AUTH-TYPE 




Octet 6 


MT-AUTH-ID (L) 






Octet L + 5 


Octet L+6 


Not used 




Octet 51 



A.2.9 RLC-AUTHENTICATION-IVIT encoding 





8 


7 


6 


1 5 1 4 1 


3 


2 


1 


Octet 4 


CHALLENGE_TO_MT 




Octet 1 9 


Octet 20 


Not used 




Octet 51 



A.2.10 RLC-AUTHENTICATION-AP-1 encoding 





8|7|6|5|4|3|2|1 


Octet 4 


CHALLENGE-TO-AP 




Octet 1 9 


Octet 20 


MT_RESPONSE 

(Possible total length over several PDUs: 16, 64, 96, 128 octets. 

Which one is given by the authentication procedure negotiated during the link capability 

phase.) 














Octet ... 


Not used (if not by MT_RESPONSE) 


Octet ... 


Octet 51 
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A.2.1 1 RLC-AUTHENTICATION-AP-2 encoding 





8|7|6|5|4|3|2|1 


Octet 4 


MT_RESPONSE 

(Possible total length over several PDUs: 16, 64, 96, 128 octets. 

Which one is given by the authentication procedure negotiated during the link capability 

phase.) 














Octet ... 


Not used (if not by MT_RESPONSE) 


Octet ... 


Octet 51 



A.2.1 2 RLC-AUTHENTICATION-AP-3 encoding 





8|7|6|5|4|3|2|1 


Octet 4 


MT_RESPONSE 

(Possible total length over several PDUs: 16, 64, 96, 128 octets. 

Which one is given by the authentication procedure negotiated during the link capability 

phase.) 














Octet ... 


Not used (if not by MT_RESPONSE) 


Octet ... 


Octet 51 



A.2.1 3 RLC-AUTHENTICATION-ACK-1 encoding 





8|7|6|5|4|3|2|1 


Octet 4 


AP_RESPONSE 

(Possible total length over several PDUs: 16, 64, 96, 128 octets. 

Which one is given by the authentication procedure negotiated during the link capability 

phase.) 














Octet ... 


Not used (if not by AP_RESPONSE) 


Octet ... 


Octet 51 



A.2.1 4 RLC-AUTHENTICATION-ACK-2 encoding 





8|7|6|5|4|3|2|1 


Octet 4 


AP_RESPONSE 

(Possible total length over several PDUs: 16, 64, 96, 128 octets. 

Which one is given by the authentication procedure negotiated during the link capability 

phase.) 














Octet ... 


Not used (if not by AP_RESPONSE) 


Octet ... 


Octet 51 
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A.2.15 RLC-AUTHENTICATION-ACK-3 encoding 





8|7|6|5|4|3|2|1 


Octet 4 


AP_RESPONSE 

(Possible total length over several PDUs: 16, 64, 96, 128 octets. 

Which one is given by the authentication procedure negotiated during the link capability 

phase.) 














Octet ... 


Not used (if not by AP_RESPONSE) 


Octet ... 


Octet 51 



A.2.16 RLC-DM-COMMON-KEY-DISTR encoding (OAP/OIVIT) 





8 1 7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


Future use 


Encryption algorithm 


Octet 5 


KEY- ID 


Octet 6 


KEY. Length according to encryption algorithm. 


Octet ... 


Octet ... 


Octet ... 


Octet ... 


Not used 


Octet ... 


Octet 51 







A.2.17 RLC-DIVI-COIVIIVION-KEY-DISTR-ACK encoding 
(OAP/OIVIT) 





8 1 7 1 6 


1 5 


4 


1 3 1 2 1 


1 


Octet 4 


Future use 


Encryption algorithm 


Octet 5 


MD5-0N-KEY 


Octet ... 


Octet 20 


Octet 21 


Not used 


Octet ... 


Octet 54 



A.2.18 RLC-INFO encoding (OAP/OMT) 





8 1 7 


6 


5 1 4 1 3 


2 


1 


Octet 4 


Future use 


Info-type 


INFO-COUNT 


DLC-attr-pr 


CL-attr-pr 


Octet 5 


Future use 


CL Attribute Length (=L1 ) (in octets) 


Octet 6 


CL-ID 


Octet 7 


CL attributes (LI ) 






Octet 7+L1 


Future use 




DLC Attribute Length (=L2) (in octets) 






DLC-Attributes 




...7+L1+L2 


Octet ... 


Not used 


Octet ... 


Octet 51 
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A.2.19 RLC-INFO-ACK encoding (OAP/OMT) 





8 1 7 1 6 


5 1 4 1 3 


2 


1 


Octet 4 


Future use 


INFO-COUNT 


DLC-attr-pr 


CL-attr-pr 


Octet 5 


Future use 


CL Attribute Length (=L1) (in octets) 




Octet 6 


CL-ID 


Octet 7 


CL attributes (L1) 






Octet 7+L1 


Future use 


DLC Attribute Length {=L2) (in octets) 






DLC-Attributes 




7+L1+L2 


Octet ... 


Not used 


Octet ... 


Octet 51 



A.2.20 RLC-UNICAST-KEY-REFRESH encoding (OAP) 





8 


7 


6 


5 1 4 


3 


2 


1 


Octet 4 


NONCE 


Octet ... 


Octet ... 


Octet 19 


Octet 20 


Not used 


Octet .. 


Octet 51 



A.2.21 RLC-UNICAST-KEY-REFRESH-ACK encoding (OAP) 





8 


7 


6 


1 5 1 4 1 


3 


2 


1 


Octet 4 


MD5-0N-N0NCE 


Octet ... 


Octet ... 


Octet 1 9 


Octet 20 


Not used 


Octet ... 


Octet 51 



A.2.22 RLC-COiVIIVION-KEY-REFRESH encoding (OAP) 





8 1 7 1 6 1 5 


4 1 3 1 2 


1 


Octet 4 


Future use 


Encr Info 


Octet 5 


KEY- ID 


Octet 6 


KEY. Length according to encryption algorithm. 


Octet ... 


Octet ... 


Octet ... 


Octet ... 


Not used 


Octet ... 


Octet 51 
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A.2.23 RLC-COMMON-KEY-REFRESH-ACK encoding (OAP) 





8 


7 1 6 


1 5 


4 1 


3 1 2 


1 


Octet 4 


Future use 


Encr Info 


Octet 5 


MD5-0N-KEY 


Octet 6 


Octet ... 


Octet ... 


Octet 21 


Octet 22 


Not used 


Octet .. 


Octet 51 



A.2.24 RLC-GROUP-JOIN encoding (OAP/OIVIT) 





8 1 7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


Length of each CL attribute in octets (L) 


Number of CL attributes (n) 


Octet 5 


CL-ID 


Octet 6 


CL-attributes 
(Higher layer group addresses) 


Octet ... 


Octet(Lxn+5) 


Octet(Lxn+6) 


Future use 


No. of encryption proposals(k) 


Octet(Lxn+7) 


Encryption proposal no. 1 


Encryption proposal no. 2 














Oct(Lxn+6+k/2) 


Encryption proposal no. k-1 


Encryption proposal no. I< 


Octet ... 


Not used 


Octet ... 


Octet 51 







A.2.25 RLC-GROUP-JOIN-ACK encoding (OAP/OIVIT) 





8 


7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


more-joins 


Future use 


Number of MAC-ID:s And CL-data (N) 


Octet 5 




Lenqth-of-CL-data in octets (L) 


Octet 6 


MAC-ID no. 1 


Octet 7 


CL-datano.1 


Octet 7+L 


Octet 


MAC-ID no. N 




CL-data no.N 


Octet Nx(L+1)+5 


Octet Nx(L+1}+6 


Future use Encryption algorithm selected 


Octet Nx(L+1)+7 


Key- ID 




Common Key. Length given by Encryption algorithm selected (K). 
K is 8 octets for DES and 24 octets for tripleDES. 




Octet Nx(L+1)+7+K 




Not used 


Octet .. 


Octet 51 
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A.2.26 RLC-GROUP-JOIN-NACK encoding (OAP/OMT) 





8 1 7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


Length of each CL attribute(L) 


Number of CL attributes(N) 


Octet 5 


CL-ID 




CL Attributes 
(Higher layer group addresses) 






Octet5+LxN 




Not used 




Octet 51 







A.2.27 RLC-GROUP-LEAVE encoding (OAP/OIVIT) 





8 1 7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


Length of each CL attribute(L) 


Number of CL attributes(n) 


Octet 5 


CL-ID 




CL Attributes 
(Higher layer group addresses) 






Octet5+LxN 




Not used 




Octet 51 







A.2.28 RLC-GROUP-LEAVE-ACK encoding (OAP/OIVIT) 





8 1 7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


Length of each CL attribute(L) 


Number of CL attributes(n) 


Octet 5 


CL-ID 




CL Attributes 
(Higher layer group addresses) 






Octet5+LxN 




Not used 




Octet 51 







A.2.29 RLC-CL-BROADCAST-JOIN encoding (OAP/OMT) 





8 1 7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


Length of each CL attribute(L) 


Number of CL attributes(N) 


Octet 5 


CL-ID 


Octet 6 


CL attributes 
(Higher layer broadcast addresses) 


Octet 7 


Octet 8 


Octet 


Octet(Lxn-i-6 


Future use 


No. of encryption proposals(k) 


Octet(Lxn-i-7 


Encryption proposal no. 1 


Encryption proposal no. 2 


Octet ... 






Oct(Lxn+6+k/2) 


Encryption proposal no. (k-1) 


Encryption proposal no. k 




Not used 




Octet 51 
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A.2.30 RLC-CL-BROADCAST-JOIN-ACK encoding (OAP/OMT) 





8 


7 


6 1 5 


4 1 3 1 2 1 1 


Octet 4 


more-joins 


rep/unack 


Window size 


No. of MAC-ID:s and CL-data(N) 


Octet 5 




Length of CL-data in octets (L) 


Octet 6 


MAC-ID no. 1 




CL-data no. 1 (L) 






MAC-ID no. 2 




CL-data no.2 






MAC-ID no. N 




CL-data no. N (L) 


Octet5+(NxL) 




Future use Encryption algorithm selected 


Octet5+(NxL)+2 


Key- ID 




Key. Length given by Encryption algorithm selected (K) 
K is 8 octets for DES and 24 octets for tripleDES 






Octet5+(NxL)+2+K 




Not used 




Octet 51 











A.2.31 RLC-CL-BROADCAST-LEAVE encoding (OAP/OiVIT) 





8 1 7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


Length of each CL attribute(L) 


Number of CL attributes(n) 


Octet 5 


CL-ID 


Octet 6 


CL attributes 
(Higher layer or peer layer broadcast addresses) 




Octet(Lxn-i-5) 




Not used 




Octet 51 







A.2.32 RLC-CL-BROADCAST-LEAVE-ACK encoding (OAP/OIVIT) 





8 1 7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


Length of each CL attribute(L) 


Number of CL attributes(N) 


Octet 5 


CL-ID 


Octet 6 


CL attributes 
(Higher layer or peer layer broadcast addresses) 




Octet LxN-k5 




Not used 




Octet 51 
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A.3 Transfer Syntax Tables for LCH RRC messages 

A.3.1 RLC-RADIO-HANDOVER-COMPLETE encoding 
(OAP/OMT) 





8 1 7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


Future use 


MAC-ID-OLD 


Octet 5 


MAC-ID-OLD 


AP-ID-OLD 


Octet 6 


AP-ID-OLD 1 NET-ID-OLD 


Octet 7 


NET-ID-OLD 


Octet 8 


MAC-ID-NEW 


Octet 9 


CL-ID 


Octet 1 


EXT-IND 1 CL-ATTRIBUTE-LENGTH(L) | # of DUC:s 


Octet 1 1 


#of DUC:s(N) 


Future use 


Octet 12 


DUC1 -DIRECTION 


DLCC-ID 




CL-ATTRIBUTES 


Octet{12+L) 


Octet Y 


DUC1-FW-TYPE-0F-ALL0CATI0N | Future 


CYCLIC-PREFIX 


FEC-usED 1 EC-MODE 


Octet ... 


DUC1 -FW-NUM-OF-RETRANSMISSIONS 


Future 


DUC1-FW-ARQ-WIN-SIZE 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REO 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet X 


DUC1-FW-TYPE-0F-ALL0CATI0N Future 


CYCLIC-PREFIX 


FEC-USED 1 EC-MODE 


Octet ... 


DUC1 -FW-NUM-OF-RETRANSMISSIONS 


Future 


DUC1-FW-ARQ-WIN-SIZE 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REO 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Not used 


Octet ... 


Octet 51 











Total length = 12h-Lh-14xN if asymmetric duplex with fixed capacity agreement and with FEC 

Total length = 12h-Lh-6xN if asymmetric duplex without fixed capacity agreement and with FEC 

Total length = 12h-Lh-7xN if symmetric duplex with fixed capacity agreement and with FEC 

Total length = 12h-Lh-3xN if symmetric duplex without fixed capacity agreement (example: Ethernet) and with FEC 

Total length = 12h-Lh-3xN if simplex without fixed capacity agreement and with FEC 

Total length = 12h-Lh-7xN if simplex with fixed capacity agreement and with FEC 

Total length = 12h-Lh-12xN if asymmetric duplex with fixed capacity agreement and without FEC 

Total length = 12h-Lh-4xN if asymmetric duplex without fixed capacity agreement and without FEC 

Total length = 12h-Lh-6xN if symmetric duplex with fixed capacity agreement and without FEC 

Total length = 12h-Lh-2xN if symmetric duplex without fixed capacity agreement and without FEC (example: Ethernet) 

Total length = 12h-Lh-2xN if simplex without fixed capacity agreement and without FEC 

Total length = 12h-Lh-6xN if simplex with fixed capacity agreement and without FEC 
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A.3.2 RLC-HANDOVER-ASSOCIATION encoding (OAP/OMT) 





8 1 7 1 6 1 5 1 4 


3 1 2 1 1 


Octet 4 


MAC-ID-OLD 


Octet 5 


Future use 


AP-ID-OLD 


Octet 6 


AP-ID-OLD 


1 NET-ID-OLD 


Octet 7 


NET-ID-OLD 


Octet 8 


MAC-ID-NEW 


Octet ... 


Future use 


Octet 51 



A.3.3 RLC-HANDOVER-LINK-CAPABILITY-ACK encoding 
(OAP/OIVIT) 





8|7|6|5|4|3|2|1 


Octet 4 


DLC version 


Octet 5 


RLC version 


Octet 6 


Freq-band-sel RSS-value 


Octet 7 


APT-ADDRESS-LENGTH 


64QAM? 1 APDMcap 


DMCkey Cycllc prefix 


Octet 8 


FCA? FSA? Future use 


ARQ-DELAY-rx 


ARQ-DELAY-tx 


Octet 9 


Authentication-Selected 


Encryption-Selected 


Octet 1 


Encrypt? | Authent? | NWTkn? | DUCSu? 


Future use 1 connections 1 Info-transfer 


Octet 1 1 


DM-ATTRIBUTES 
(only present if APDM-cap is set) 


Octet 12 


Octet 1 3 


Octet 1 4 


Octet 1 5 


Octet 1 6 


Octet 1 7 


Octet 1 8 


Octet ... 


Not used 


Octet ... 


Octet 51 









A.3.4 RLC-NW-SIGNALLING-HANDOVER encoding (OAP/OIVIT) 





8 


7 


1 6 1 5 1 4 1 3 1 


2 


1 


Octet 4 


MD5-0N-MT-T0KEN-AUTH-ENCR 






Octet 1 9 


Octet 20 


Not used 


Octet ... 


Octet 51 
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A.3.5 RLC-NW-SIGNALLING-HANDOVER-ACK encoding 
(OAP/OMT) 





8|7|6|5|4|3|2|1 


Octet 4 


AP-token 




Octet 1 9 


Octet 20 




Auth/Encr-No-of-Proposals (K) 


Octet 21 


Authentication-Proposal-#1 


Encryption-Proposal-#1 








Octet 20+K 


Authentication-Proposal-#K 


Encryption-Proposal-#K 


Octet 21 +K 


Authentication-Proposal-Selected 


Encryption-Proposal-Selected 


Octet .. 


Future use 


Octet .. 


Octet 51 







A.3.6 RLC-NETWORK-HANDOVER-COMPLETE encoding 
(OAP/OIVIT) 





8|7|6|5|4|3|2|1 


Octet 4 


CL-ID 


Octet 5 


EXT-IND 1 CL-ATTRIBUTE-LENGTH(L) | # of DUC:s 


Octet 6 


#of DUC:s(N) 


Future use 


Octet 7 


DUC1 -DIRECTION 


DLCC-ID 




CL-ATTRIBUTES 


Octet{7-HL) 


Octet Y 


DUC1-FW-TYPE-0F-ALL0CATI0N | Future 


Cyclic-pref 


FEC-USED 1 EC-MODE 


Octet ... 


DUC1 -FW-NUM-OF-RETRANSMISSIONS 


Future 


DUC1-FW-AR0-WIN-SIZE 




FEC-FW 


Future Use 


Octet ... 


PER-#-l\/IAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REO 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet X 


DUC1-BW-TYPE-0F-ALL0CATI0N Future 


Cyclic-pref 


FEC-USED 1 EC-MODE 


Octet ... 


DUC1 -BW-NUM-OF-RETRANSMISSIONS 


Future 


DUC1-BW-AR0-WIN-SIZE 




FEC-BW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REO 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet... 


MlNUMUM-NUM-OF-LCH 


Octet ... 


Not used 


Octet ... 


Octet 51 











Total length = 7h-Lh-14xN if asymmetric duplex with fixed capacity agreement and with FEC 

Total length = 7h-Lh-6xN if asymmetric duplex without fixed capacity agreement and with FEC 

Total length = 7h-Lh-7xN if symmetric duplex with fixed capacity agreement and with FEC 

Total length = 7h-Lh-3xN if symmetric duplex without fixed capacity agreement (example: Ethernet) and with FEC 

Total length = 7h-Lh-3xN if simplex without fixed capacity agreement and with FEC 

Total length = 7h-Lh-7xN if simplex with fixed capacity agreement and with FEC 

Total length = 7h-Lh-12xN if asymmetric duplex with fixed capacity agreement and without FEC 

Total length = 7h-Lh-4xN if asymmetric duplex without fixed capacity agreement and without FEC 

Total length = 7h-Lh-6xN if symmetric duplex with fixed capacity agreement and without FEC 

Total length = 7h-Lh-2xN if symmetric duplex without fixed capacity agreement and without FEC (example: Ethernet) 
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Total length = 7+L+2xN if simplex without fixed capacity agreement and without FEC 
Total length = 7+L+6xN if simplex with fixed capacity agreement and without FEC 

A.3.7 RLC-HO-INFO-DISTRIBUTION encoding (OAP/OMT) 





8 


7 


6 


5 1 4 


3 


2 


1 


Octet 4 


TOKEN 


Octet ... 


Octet ... 


Octet 1 9 


Octet 20 


Not used 


Octet ... 


Octet 51 



A.3.8 RLC-DFS-MEASUREMENT-COMPLETE-REQUEST 
encoding 





8|7|6|5|4|3|2|1 


Octet 4 


FREOUENCY-INDEX 


Octet 5 


Future use | UOA | START-OF-MEASUREMENT 


Octet 6 


Future use | MEASUREMENT-WINDOW 


Octet 7 


Future use | MAXIMUM-AGE-OF-MEASUREMENT 


Octet 8 


MAXIMUM-AGE-OF-MEASUREMENT 


Octet 9 


Future use 


RSS-INDEX 1 


Octet 10 


RSS-INDEX2 


RSS-INDEX3 


Octet 1 1 


RSS-INDEX4 


RSS-INDEX 5 


Octet ... 


Not used 


Octet ... 


Octet 51 







A.3.9 RLC-DFS-IVIEASUREIVIENT-PERCENTILES-REQUEST 
encoding 





8 1 7 1 6 


1 5 1 4 1 3 1 2 1 1 


Octet 4 


FREOUENCY-INDEX 


Octet 5 


Future use 


1 UOA 1 START-OF-MEASUREMENT 


Octet 6 


Future use 


MEASUREMENT-WINDOW 


Octet 7 


Future use 


Octet 8 


Octet 9 


Future use 


RSS-INDEX 1 


Octet 10 


RSS-INDEX 2 


RSS-INDEX 3 


Octet 1 1 


RSS-INDEX 4 


RSS-INDEX 5 


Octet ... 


Not used 


Octet ... 


Octet 51 



A.3.10 RLC-DFS-IVIEASUREIVIENT-SHORT-REQUEST encoding 





8|7|6|5|4|3|2|1 


Octet 4 


FREOUENCY-INDEX 


Octet 5 


Future use | UOA | START-OF-MEASUREMENT 


Octet 6 


Future use | MEASUREMENT-WINDOW 


Octet 7 


Future use | MAXIMUM-AGE-OF-MEASUREMENT 


Octet 8 


MAXIMUM-AGE-OF-MEASUREMENT 


Octet ... 


Not used 


Octet ... 


Octet 51 
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A.3.1 1 RLC-DFS-REPORT-COMPLETE encoding 





8 1 7 1 6 


1 5 1 4 1 3 1 2 1 1 


Octet 4 


FREOUENCY-INDEX 


Octet 5 


Future use 


1 UOA 1 AGE-OF-MEASUREMENT 


Octet 6 


AGE-OF-MEASUREMENT 


Octet 7 


Future use 


LAST-OWN-BCH-RX-LEVEL 


Octet 8 


Future use 


NUMBER-OF-SAMPLES 


Octet 9 


NUMBER-OF-SAMPLES 


Octet 1 


BCH- Future use 


1 TRAFFIC-LOAD | AP-ID 


Octet 1 1 


AP-ID 


Octet 1 2 


Future use 


TX-LEVEL 1 NET-ID 


Octet 1 3 


NET-ID 


Octet 14 


Future use 


BCH-RX-LEVEL 


Octet 1 5 


Future use 


RSS-INDEX 1 


Octet 16 


RSS-INDEX2 


RSS-INDEX3 


Octet 1 7 


RSS-INDEX4 


RSS-INDEX 5 


Octet 1 8 


Future use 


RSS-STATISTICS 1 


Octet 1 9 


Future use 


RSS-STATISTICS 2 


Octet 20 


Future use 


RSS-STATISTICS 3 


Octet 21 


Future use 


RSS-STATISTICS 4 


Octet 22 


Future use 


RSS-STATISTICS 5 


Octet 23 




Not used 


Octet ... 


Octet 51 











A.3.1 2 RLC-DFS-REPORT-PERCENTILES encoding 





8 1 7 1 6 


1 5 1 4 1 3 1 2 


1 


Octet 4 


FREOUENCY-INDEX 


Octet 5 


Future use 


UOA Future use 




Octet 6 


Future use 


Octet 7 


Future use 


LAST-OWN-BCH-RX-LEVEL 


Octet 8 


Future use 


NUMBER-OF-SAMPLES 


Octet 9 


NUMBER-OF-SAMPLES 


Octet 1 


Future use 


Octet 1 1 


Octet 12 


Octet 1 3 


Octet 1 4 


Octet 1 5 


Future use 


RSS-INDEX 1 


Octet 16 


RSS-INDEX 2 


RSS-INDEX 3 


Octet 17 


RSS-INDEX 4 


RSS-INDEX 5 


Octet 1 8 


Future use 


RSS-STATISTICS 1 


Octet 1 9 


Future use 


RSS-STATISTICS 2 


Octet 20 


Future use 


RSS-STATISTICS 3 


Octet 21 


Future use 


RSS-STATISTICS 4 


Octet 22 


Future use 


RSS-STATISTICS 5 


Octet 23 


Not used 


Octet ... 


Octet 51 
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A.3.13 RLC-DFS-REPORT-SHORT encoding 



Octet 4 



FREQUENCY-INDEX 



Octet 5 



Future use 



UOA 



AGE-OF-MEASUREMENT 



Octet 6 



AGE-OF-MEASUREMENT 



Octet 7 



Future use 



LAST-OWN-BCH-RX-LEVEL 



Octet 8 



Octet 9 



Future use 



Octet 1 



BCH- 



Future use 



TRAFFIC-LOAD 



AP-ID 



Octet 1 1 



AP-ID 



Octet 12 



Future use 



TX-LEVEL 



NET-ID 



Octet 13 



NET-ID 



Octet 14 



Future use 



BCH-RX-LEVEL 



Octet 1 5 



Octet ... 



Octet 51 



Not used 



A.4 Transfer Syntax Tables for LCH DUCC messages 



A.4.1 RLC-SETUP encoding 





8|7|6|5|4|3|2|1 


Octet 4 


CL-ID 


Octet 5 


duc-ext 1 CL-ATTRIBUTE-LENGTH(L) | # of DUC:s 


Octet 6 


#of DUC:s(N) 


Future use 


Octet 7 


DUC1-DIRECTI0N 


DLCC-ID 




CL-CONN ATTR 


Octet 7-hL 


Octet Y 


DUC1-FW-TYPE-0F-ALL0CATI0N | Future 


CYCLIC-PREFIX 


FEC- 1 EC-MODE 


Octet ... 


DUC1 -FW-NUM-OF-RETRANSMISSIONS 


Future 


DUC1-FW-ARQ-WIN-SIZE 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REO 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet X 


DUC1-BW-TYPE-0F-ALL0CATI0N Future 


CYCLIC-PREFIX 


FEC- 1 EC-MODE 


Octet ... 


DUC1 -BW-NUM-OF-RETRANSMISSIONS 


Future 


DUC1-BW-ARQ-WIN-SIZE 




FEC-BW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REO 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Not used 


Octet ... 


Octet 51 











Total length = 7-i-L-i-14xN if asymmetric duplex with fixed capacity agreement and with FEC 

Total length = 7-i-L-i-6xN if asymmetric duplex without fixed capacity agreement and with FEC 

Total length = 7-i-L-i-7xN if symmetric duplex with fixed capacity agreement and with FEC 

Total length = 7-i-L-i-3xN if symmetric duplex without fixed capacity agreement (example: Ethernet) and with FEC 

Total length = 7-i-L-i-3xN if simplex without fixed capacity agreement and with FEC 

Total length = 7-i-L-i-7xN if simplex with fixed capacity agreement and with FEC 

Total length = 7-i-L-i-12xN if asymmetric duplex with fixed capacity agreement and without FEC 

Total length = 7-i-L-i-4xN if asymmetric duplex without fixed capacity agreement and without FEC 
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Total length = 7+L+6xN if symmetric duplex with fixed capacity agreement and without FEC 

Total length = 7+L+2xN if symmetric duplex without fixed capacity agreement and without FEC (example: Ethernet) 

Total length = 7+L+2xN if simplex without fixed capacity agreement and without FEC 

Total length = 7+L+6xN if simplex with fixed capacity agreement and without FEC 



A.4.2 RLC-CONNECT encoding 





8|7|6|5|4|3|2|1 


Octet 4 


CL-ID 


Octet 5 


Future | CL-ATTRIBUTE-LENGTH(L) | # of DUC:s 


Octet 6 


#of DUC:s(N) 


Future use 


Octet 7 


DUC1-DIRECTI0N 


DLCC-ID 




CL-CONN ATTR 


Octet 7+L 


Octet Y 


DUC1-FW-TYPE-0F-ALL0CATI0N Future 


CYCLIC-PREFIX 


FEC- 1 EC-MODE 


Octet ... 


DUC1 -FW-NUM-OF-RETRANSMISSIONS 


Future 


DUC1-FW-ARQ-WIN-SIZE 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REQSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet X 


DUC1-BW-TYPE-0F-ALL0CATI0N | Future 


CYCLIC-PREFIX 


FEC- 1 EC-MODE 


Octet ... 


DUC1-BW-NUM-0F-RETRANSMISSI0NS 


Future 


DUC1 -BW-ARO-WIN-SIZE 




FEC-BW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REQSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Not used 


Octet ... 


Octet 51 











Total length = 7h-Lh-14xN if asymmetric duplex with fixed capacity agreement and with FEC 

Total length = 7h-Lh-6xN if asymmetric duplex without fixed capacity agreement and with FEC 

Total length = 7h-Lh-7xN if symmetric duplex with fixed capacity agreement and with FEC 

Total length = 7h-Lh-3xN if symmetric duplex without fixed capacity agreement (example: Ethernet) and with FEC 

Total length = 7h-Lh-3xN if simplex without fixed capacity agreement and with FEC 

Total length = 7h-Lh-7xN if simplex with fixed capacity agreement and with FEC 

Total length = 7h-Lh-12xN if asymmetric duplex with fixed capacity agreement and without FEC 

Total length = 7h-Lh-4xN if asymmetric duplex without fixed capacity agreement and without FEC 

Total length = 7h-Lh-6xN if symmetric duplex with fixed capacity agreement and without FEC 

Total length = 7h-Lh-2xN if symmetric duplex without fixed capacity agreement and without FEC (example: Ethernet) 

Total length = 7h-Lh-2xN if simplex without fixed capacity agreement and without FEC 

Total length = 7h-Lh-6xN if simplex with fixed capacity agreement and without FEC 
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A.4.3 RLC-CONNECT-ACK encoding 





8|7|6|5|4|3|2|1 


Octet 4 


CL-ID (filled with same contents as setup message) 


Octet 5 


Future | CL-CONN-ATTR-LENGTH(L) | # of DLCC+CL-CON- 


Octet 6 


# of DLCC+CL-CON- 


Future use 


Octet ... 


Future use 


DLCC-ID-1 


Octet ... 


CL-CONN-ATTR-1 


Octet ... 


Octet ... 


Future use | DLCC-ID-2 


Octet ... 


CL-CONN ATTR-2 


Octet ... 


Octet ... 


Not used 


Octet ... 


Octet 51 







A.4.4 RLC-RELEASE encoding 





8 1 7 1 6 


5 


4 1 3 1 2 1 


1 


Octet 4 


Future use 


RELEASE-CAUSE 


Octet 5 


Future use 


# of DLCC-ID (N) 


Octet ... 


Future use 


DLCC-ID#1 




Future use 


DLCC-ID... 


Octet 5+N 


Future use 


DLCC-ID#N 


Octet ... 


Not used 


Octet ... 


Octet 51 



A.4.5 RLC-RELEASE-ACK encoding 





8 1 7 1 6 


5 


4 1 3 1 2 1 


1 


Octet 4 


Future use 


# of DLCC-ID (N) 


Octet ... 


Future use 


DLCC-ID#1 




Future use 


DLCC-ID... 


Octett 4-i-N 


Future use 


DLCC-ID#N 


Octet ... 


Not used 


Octet ... 


Octet 51 
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A.4.6 RLC-MODIFY-REQUEST encoding (OAP/OMT) 





8 


7 1 6 1 5 1 4 1 3 


2 1 1 


Octet 4 


duc-ext-ind 


CL-ATTRIBUTE-LENGTH(L) 


#of DUC:s 


Octet 5 


#of DUC:s(N) 


Future use 


Octet 6 


DUC1-DIRECTI0N 


DLCC-ID 




CL-CONN ATTR 


Octet 6+L 


Octet Y 


DUC1-FW-TYPE-0F- | Future 


CYCLIC-PREFIX 


FEC- 1 EC-MODE 


Octet ... 


DUC1-FW-NUM-0F-RETRANSMISSI0NS 


Future 


DUC1 -FW-ARO-WIN-SIZE 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REO 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet X 


DUC1-BW-TYPE-0F- | Future 


CYCLIC-PREFIX 


FEC- 1 EC-MODE 


Octet ... 


DUC1 -BW-NUM-OF-RETRANSMISSIONS 


Future 


DUC1-BW-ARQ-WIN-SIZE 




FEC-BW 


Future Use 


Octet... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REO 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Not used 


Octet ... 


Octet 51 















Total length = 6h-Lh-14xN if asymmetric duplex with fixed capacity agreement and with FEC 

Total length = 6h-Lh-6xN if asymmetric duplex without fixed capacity agreement and with FEC 

Total length = 6h-Lh-7xN if symmetric duplex with fixed capacity agreement and with FEC 

Total length = 6h-Lh-3xN if symmetric duplex without fixed capacity agreement (example: Ethernet) and with FEC 

Total length = 6h-Lh-3xN if simplex without fixed capacity agreement and with FEC 

Total length = 6h-Lh-7xN if simplex with fixed capacity agreement and with FEC 

Total length = 6h-Lh-12xN if asymmetric duplex with fixed capacity agreement and without FEC 

Total length = 6h-Lh-4xN if asymmetric duplex without fixed capacity agreement and without FEC 

Total length = 6h-Lh-6xN if symmetric duplex with fixed capacity agreement and without FEC 

Total length = 6h-Lh-2xN if symmetric duplex without fixed capacity agreement and without FEC (example: Ethernet) 

Total length = 6h-Lh-2xN if simplex without fixed capacity agreement and without FEC 

Total length = 6h-Lh-6xN if simplex with fixed capacity agreement and without FEC 
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A.4.7 RLC-MODIFY encoding (OAP/OMT) 





8 


7 1 6 1 5 1 4 1 3 


2 1 1 


Octet 4 


Future 


CL-ATTRIBUTE-LENGTH(L) 


#of DUC:s 


Octet 5 


#of DUC:s(N) 


Future use 


Octet 6 


DUC1-DIRECTI0N 


DLCC-ID 




CL-CONN ATTR 


Octet 6+L 


Octet Y 


DUC1-FW-TYPE-0F- | Future 


CYCLIC-PREFIX 


FEC- 1 EC-MODE 


Octet ... 


DUC1-FW-NUM-0F-RETRANSMISSI0NS 


Future 


DUC1 -FW-ARO-WIN-SIZE 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REO 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet X 


DUC1-BW-TYPE-0F- | Future 


CYCLIC-PREFIX 


FEC- 1 EC-MODE 


Octet ... 


DUC1 -BW-NUM-OF-RETRANSMISSIONS 


Future 


DUC1-BW-ARQ-WIN-SIZE 




FEC-BW 


Future Use 


Octet... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REO 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Not used 


Octet ... 


Octet 51 















Total length = 6h-Lh-14xN if asymmetric duplex with fixed capacity agreement and with FEC 

Total length = 6h-Lh-6xN if asymmetric duplex without fixed capacity agreement and with FEC 

Total length = 6h-Lh-7xN if symmetric duplex with fixed capacity agreement and with FEC 

Total length = 6h-Lh-3xN if symmetric duplex without fixed capacity agreement (example: Ethernet) and with FEC 

Total length = 6h-Lh-3xN if simplex without fixed capacity agreement and with FEC 

Total length = 6h-Lh-7xN if simplex with fixed capacity agreement and with FEC 

Total length = 6h-Lh-12xN if asymmetric duplex with fixed capacity agreement and without FEC 

Total length = 6h-Lh-4xN if asymmetric duplex without fixed capacity agreement and without FEC 

Total length = 6h-Lh-6xN if symmetric duplex with fixed capacity agreement and without FEC 

Total length = 6h-Lh-2xN if symmetric duplex without fixed capacity agreement and without FEC (example: Ethernet) 

Total length = 6h-Lh-2xN if simplex without fixed capacity agreement and without FEC 

Total length = 6h-Lh-6xN if simplex with fixed capacity agreement and without FEC 

A.4.8 RLC-MODIFY-ACK encoding (OAP/OIVIT) 





8 


7 


6 1 5 1 4 1 3 


2 1 1 


Octet 4 


Future use 


CL-CONN-ATTR-LENGTH(L) 


# of DLCC+CL-CON-ATT 


Octet 5 


# of DLCC+CL-CON-ATT(N) 


Future use 


Octet ... 


Future use 


DLCC-ID-1 


Octet ... 


CL-CONN-ATTR-1 


Octet ... 


Octet ... 


Future use 


DLCC-ID-2 




Octet ... 


CL-CONN-ATTR-2 


Octet 5+(L+1)xN 


Octet ... 


Not used 


Octet ... 


Octet 51 
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Total length= 5+(L+l)xN 



A.4.9 RLC-RESET, RLC-RESET-ACK encoding 





8 1 7 1 6 1 5 


4 1 3 1 2 1 1 


Octet 4 


Future use 


#of DLCC:s(N) 


Octet 5 


Future use 


DLCC-ID-1 


Octet 6 


Future use 


DLCC-ID... 


Octet 4+N 


Future use 




Octet ... 


Not used 


Octet ... 


Octet 51 









A.4.10 RLC-DM-SETUP encoding (OAP/OIVIT) 





8 |7|6|5|4|3|2|1 


Octet 4 


MAC-ID 


Octet 5 


CL-ID 


Octet 6 


EXT-IND 1 CL-ATTRIBUTE-LENGTH(L) | # of DUC:s 


Octet 7 


#of DUC:s(N) 


Future use 


Octet 8 


DUC1 -DIRECTION 


DLCC-ID 




CL-CONN ATTR 




Octet Y 


DUC1-FW-TYPE-0F- | Future 


CYCLIC-PREFIX 


FEC- 1 EC-MODE 


Octet ... 


DUC1 -FW-NUM-OF-RETRANSMISSIONS 


Future 


DUC1-FW-ARQ-WIN-SIZE 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REO 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REOUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet X 


DUC1-BW-TYPE-0F- | Future 


CYCLIC-PREFIX 


FEC- 1 EC-MODE 


Octet ... 


DUC1-BW-NUM-0F-RETRANSMISSI0NS 


Future 


DUC1-BW-ARQ-WIN-SIZE 




FEC-BW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REO 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REOUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


CL-COMMON-ATTR 


Octet ... 


Octet ... 


Octet ... 


Not used 


Octet ... 


Octet 51 











Y=8h-L 

X=8-i-Lh-6 if asymmetric duplex with polling and ARQ or FEC 
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A.4.1 1 RLC-DM-CONNECT encoding (OAP/OMT) 





8|7|6|5|4|3|2|1 


Octet 4 


MAC-ID 


Octet 5 


CL-ID 


Octet 6 


Future use | CL-ATTRIBUTE-LENGTH(L) | # of DUC:s 


Octet 7 


#of DUC:s(N) 


Future use 


Octet 8 


DUC1-DIRECTI0N 


DLCC-ID 




CL-CONN ATTR 




Octet Y 


DUC1-FW-TYPE-0F-ALL0CATI0N Future use 


CYCUC-PREFIX 


FEC-USED 1 EC-MODE 


Octet ... 


DUC1 -FW-NUM-OF-RETRANSMISSIONS 


Future use 


DUC1-FW-ARQ-WIN-SIZE 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REQSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet X 


DUC1-BW-TYPE-OF-ALL0CATION Future use 


CYCUC-PREFIX 


FEC-USED 1 EC-MODE 


Octet ... 


DUC1 -BW-NUM-OF-RETRANSMISSIONS 


Future use 


DUC1-BW-ARQ-WIN-SIZE 




FEC-BW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REQSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REOUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 




Octet ... 


Octet 51 






1 



A.4.12 RLC-DM-CONNECT-ACK encoding (OAP/OIVIT) 





8 1 7 


6 1 5 1 4 1 3 


1 2 1 1 1 


Octet 4 


MAC-ID 


Octet 5 


CL-ID 


Octet 6 


Future use 1 


CL-CONN-ATTR-LENGTH (L) 


# of DLCC:s+CL-ATTR 


Octet 7 


# Of DLCCs (N) 


Future use 


Octet 8 


Future use 


DLCC-ID-1 


Octet ... 


CL-CONN-ATTR-1 


Octet ... 


Future use 


DLCC-ID-N 




Octet ... 


CL-CONN-ATTR-N 


Octet 
8-hL*N 


Octet ... 


Not used 


Octet ... 


Octet 51 



A.4.1 3 RLC-DIVI-CONNECT-COIVIPLETE encoding (OAP/OIVIT) 





8 1 7 1 6 


5 1 4 1 3 1 2 1 


1 1 


Octet 4 


MAC-ID 1 


Octet 5 


Future use 


1 # of DLCC:s (N) 




Octet 6 


Future use 


DLCC-ID-1 


Octet ... 


Future use 




Octet 5-hN 


Future use 


DLCC-ID-N 


Octet 6-hN 


Not used 


Octet ... 


Octet 51 
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A.4.14 RLC-RELAY-SETUP encoding (OAP/OMT) 





8 |7|6|5|4|3|2|1 


Octet 4 


MAC-ID 


Octet 5 


CL-ID 


Octet 6 


EXT-IND 1 CL-ATTRIBUTE-LENGTH(L) | # of DUC:s 


Octet 7 


#of DUC:s(N) 


Future use 


Octet 8 


DUC1-DIRECTI0N 


DLCC-ID 




CL-CONN ATTR 




Octet Y 


DUC1-FW-TYPE-0F-ALL0CATI0N Future 


CYCLIC-PREFIX 


FEC-USED 1 EC-MODE 


Octet ... 


DUC1 -FW-NUM-OF-RETRANSMISSIONS 


Future 


DUC1-FW-AR0-WIN-SIZE 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REOSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet X 


DUC1-BW-TYPE-0F-ALL0CATI0N | Future 


CYCLIC-PREFIX 


FEC-USED 1 EC-MODE 


Octet ... 


DUC1 -BW-NUM-OF-RETRANSMISSIONS 


Future 


DUC1 -BW-ARO-WIN-SIZE 




FEC-BW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REOSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REQUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


CL-COMMON-ATTR 


Octet ... 


Octet ... 


Octet ... 


Not used 


Octet ... 


Octet 51 











A.4.15 RLC-DM-RELAY-SETUP-ACK encoding (OAP/OIVIT) 





8 1 7 


6 1 5 1 4 1 3 


2 1 1 1 


Octet 4 


MAC-ID 1 


Octet 5 


Future use 1 


CL-CONN-ATTR-LENGTH 


# of DLCC:s 1 


Octet 6 


# Of DLCCs 


Future use 


Octet 7 


Future use 


DLCC-ID-1 


Octet ... 


CL-CONN-ATTR-1 


Octet ... 


Future use 


DLCC-ID 




Octet ... 


CL-CONN-ATTR 


Octet ... 


Not used 


Octet ... 


Octet 51 
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A.4.16 RLC-DM-MODIFY-REQ encoding (OAP/OMT) 





8|7|6|5|4|3|2|1 


Octet 4 


MAC-ID 


Octet 5 


Future | CL-ATTRIBUTE-LENGTH(L) | #ofDUC:s 


Octet 6 


#of DUC:s(N) 


Future use 


Octet 7 


DUC1-DIRECTI0N 


DLCC-ID 




CL-CONN ATTR 




Octet Y 


DUC1-FW-TYPE-0F-ALL0CATI0N | Future 


CYCLIC-PREFIX 


FEC-USED 1 EC-MODE 


Octet ... 


DUC1-FW-NUM-0F-RETRANSMISSI0NS 


Future 


DUC1-FW-ARQ-WIN-SIZE 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REQSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REOUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet X 


DUC1-BW-TYPE-0F-ALL0CATI0N Future 


CYCLIC-PREFIX 


FEC-USED 1 EC-MODE 


Octet ... 


DUC1-BW-NUM-0F-RETRANSMISSI0NS 


Future 


DUC1-BW-AR0-WIN-SIZE 




FEC-BW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REQSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REOUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Not used 


Octet ... 


Octet 51 











A.4.17 RLC-DM-MODIFY encoding (OAP/OIVIT) 





8|7|6|5|4|3|2|1 


Octet 4 


MAC-ID 


Octet 5 


Future | CL-ATTRIBUTE-LENGTH(L) | # of DUC:s 


Octet 6 


#of DUC:s(N) 


Future use 


Octet 7 


DUC1-DIRECTI0N 


DLCC-ID 




CL-CONN ATTR 




Octet Y 


DUC1-FW-TYPE-0F-ALL0CATI0N | Future 


CYCLIC-PREFIX 


FEC-USED 1 EC-MODE 


Octet ... 


DUC1 -FW-NUM-OF-RETRANSMISSIONS 


Future 


DUC1-FW-AR0-WIN-SIZE 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REQSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REOUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet X 


DUC1-BW-TYPE-0F-ALLQGATI0N Future 


CYCLIC-PREFIX 


FEC-USED 1 EC-MODE 


Octet ... 


DUC1-BW-NUM-0F-RETRANSMISSI0NS 


Future 


DUC1-BW-ARQ-WIN-SIZE 




FEC-BW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REQSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REOUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Not used 


Octet ... 


Octet 51 
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A.4.18 RLC-DM-MODIFY-ACK encoding (OAP/OMT) 





8 |7|6|5|4|3|2|1 


Octet 4 


MAC-ID 


Octet 5 


CL-CONN-ATTR-LENGTH | # of DLCC:s+CL-CONN-ATTR 


Octet 6 


#ofDLCCs 1 Future use 


Octet 7 


Future use | DLCC-ID-1 


Octet ... 


CL-CONN-ATTR-1 




Future use DLCC-ID... 




CL-CONN-ATTR ... 




Not used 




Octet 51 



A.4.19 RLC-DM-MODIFY-COMPLETE encoding (OAP/OIVIT) 





8 1 7 1 6 


5 1 4 1 3 1 2 


1 1 


Octet 4 


MAC-ID 1 


Octet 5 


Future use 


1 # of DLCC:s 




Octet 6 


Future use 


DLCC-ID-1 


Octet 7 


Future use 


DLCC-ID... 


Octet ... 


Not used 


Octet ... 


Octet 51 



A.4.20 RLC-DIVI-RELAY-IVIODIFY encoding (OAP/OIVIT) 





8|7|6|5|4|3|2|1 


Octet 4 


MAC-ID 


Octet 5 


Future use | CL-ATTRIBUTE-LENGTH(L) | # of DUC:s 


Octet 6 


#of DUC:s(N) 


Future use 


Octet 7 


DUC1-DIRECTI0N 


DLCC-ID 




CL-CONN ATTR 




Octet Y 


DUC1-FW-TYPE-0F-ALLOCATION 1 Future use 


CYCLIC-PREFIX 


FEC-USED 1 EC-MODE 


Octet ... 


DUC1 -FW-NUM-OF-RETRANSMISSIONS 


Future use 


DUC1-FW-ARQ-WIN-SIZE 




FEC-FW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REQSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REOUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet X 


DUC1-BW-TYPE-0F-ALL0CATI0N 1 Future use 


CYCLIC-PREFIX 


FEC-USED 1 EC-MODE 


Octet ... 


DUC1 -BW-NUM-OF-RETRANSMISSIONS 


Future use 


DUC1-BW-ARQ-WIN-SIZE 




FEC-BW 


Future Use 


Octet ... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet ... 


REQSCH 1 PHY-MODE-SCH 


PHY-MODE-LCH 


Octet ... 


REOUESTED-NUM-OF-LCH 


Octet ... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Mn4 . ,r^^^ 


Octet ... 


Octet 51 
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A.4.21 RLC-DM-RELAY-MODIFY-ACK encoding (OAP/OMT) 





8 1 7 


6 1 5 1 4 1 3 


2 1 1 


Octet 4 


MAC-ID 


Octet 5 


Future use 1 


GL-CONN-ATTR-LENGTH 


# of DLCC:s 


Octet 6 


# Of DLGGs 


Future use 


Octet 7 


Future use 


DLGG-ID-1 


Octet ... 


CL-CONN-ATTR-1 


Octet ... 


Future use 


DLGG-ID 




Octet ... 


CL-CONN-ATTR 


Octet ... 


Not used 


Octet... 


Octet 51 



A.4.22 RLC-DM-RELEASE encoding (OAP/OIVIT) 





8 1 7 1 6 


5 1 4 1 3 1 2 


1 


Octet 4 


MAC-ID 


Octet 5 


CAUSE 


1 # of DLCC:s 




Octet 6 


Future use 


DLCG-ID-1 


Octet 7 


Future use 




Octet ... 


Future use 


DLCG-IDN 


Octet ... 


Not used 


Octet... 


Octet 51 



A.4.23 RLC-DIVI-RELEASE-ACK encoding (OAP/OIVIT) 





8 1 7 1 6 


5 1 4 1 3 1 2 


1 


Octet 4 


MAC-ID 


Octet 5 


Future use 


1 # of DLCC:s 




Octet 6 


Future use 


DLGC-ID-1 


Octet 7 


Future use 




Octet ... 


Future use 


DLCC-ID-N 


Octet ... 


Not used 


Octet... 


Octet 51 



A.4.24 RLC-DM-RELAY-RELEASE encoding (OAP/OMT) 





8 1 7 1 6 


5 1 4 1 3 1 2 


1 


Octet 4 


MAC-ID 


Octet 5 


CAUSE 


1 # of DLCC:s 




Octet 6 


Future use 


DLCC-ID-1 


Octet 7 


Future use 




Octet ... 


Future use 


DLCC-ID-N 


Octet ... 


Not used 


Octet... 


Octet 51 
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A.4.25 RLC-DM-RELAY-RELEASE-ACK encoding (OAP/OMT) 





8 1 7 1 6 


5 1 4 1 3 1 2 


1 


Octet 4 


MAC-ID 


Octet 5 


Future use 


1 # of DLCC:s 




Octet 6 


Future use 


DLGG-ID-1 


Octet 7 


Future use 




Octet ... 


Future use 


DLGG-IDN 


Octet ... 


Not used 


Octet... 


Octet 51 



A.4.26 RLC-DM-RESET, RLC-DM-RESET-ACK encoding 
(OAP/OIVIT) 





8 1 7 1 6 


5 1 4 1 3 1 2 


1 


Octet 4 


MAC-ID 


Octet 5 


Future use 


1 # of DLCC:s 




Octet 6 


Future use 


DLGG-ID-1 


Octet 7 


Future use 


DLGG-ID... 


Octet ... 


Future use 




Octet ... 


Not used 


Octet ... 


Octet 53 



A.5 Transfer Syntax Tables for SCH ACF messages 
A.5.1 RLC-RBCH-ASSOCIATION-REQUEST encoding (OIVIT) 





8 


7 


6 1 5 1 4 


3 


2 1 1 


Octet 3 




AP-ID 


Octet 4 


AP-ID 


Octet 5 






Future use 




NET-ID 


Octet 6 


NET-ID 


Octet 7 


MAC-ID 



A.5.2 RLC-IVIAC-ID-ASSIGN encoding 





8 


7 


6 


1 5 1 4 1 


3 


2 1 1 


Octet 3 




Future use 


Octet 4 


MAGIC 


Octet 5 


Octet 6 


RLG-VERSION 


Octet 7 


MAC-ID 



A.5.3 RLC-IVIAC-ID-ASSIGN-ACK encoding 





8 


7 


6 


5 1 4 


1 3 1 


2 


1 


Octet 3 




Future use 


Octet 4 


MAGIC 


Octet 5 


Octet 6 


MAC-ID 


Octet 7 


MAC-ID 
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A.5.4 RLC-MAC-ID-ASSIGN-NACK encoding 





8 


7 


6 


5 1 4 


1 3 1 


2 


1 


Octet 3 




Future use 


Octet 4 


MAGIC 


Octet 5 


Octet 6 


Future use 


Octet 7 



A.5.5 RLC- RLC-COMMON-KEY-ACTIVATE encoding (GAP) 





8 


7 


6 


5 1 4 


1 3 1 


2 


1 


Octet 3 




Future use 


Octet 4 


KEY- ID 


Octet 5 


Not used 


Octet 6 


Octet 7 



A.5.6 RLC-DISASSOCIATION encoding 





8 


7 1 6 


1 5 1 4 1 3 


2 1 1 


Octet 3 




Future use 


Octet 4 




Future use 


1 DISASSOCIATION-CAUSE 


Octet 5 


Future use 


Octet 6 


Octet 7 


MAC-ID (if sent in UL) 



A.5.7 RLC-DISASSOCIATION-ACK encoding 





8 


7 


6 


1 5 1 4 


3 


2 1 1 


Octet 3 




Future use 


Octet 4 


Future use 


Octet 5 


Octet 6 


Octet 7 


MAC-ID (if UL) 



A.5.8 RLC-PROCEEDING encoding 





8 1 7 1 6 1 5 1 4 1 


3 


2 


1 


Octet 3 




Future 


SCH-LCH 


Octet 4 


Proceeded-PDU-type 


Octet 5 


Future use 


EXTENSION-TYPE 


Octet 6 


Future use 


Octet 7 


MAC-ID (if UL) 
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A.6 Transfer Syntax Tables for SCH RRC messages 

A.6.1 RLC-SECTOR-HANDOVER-REQUEST encoding 
(OAP/OMT) 





8 


7 


1 6 1 


5 1 4 


3 


2 1 1 


Octet 3 




Future Use 


Octet 4 






Future use 






SECTOR-ID 


Octet 5 


Future use 


Octet 6 


Octet 7 


MAC-ID 



A.6.2 RLC-SECTOR-HANDOVER-ACK encoding (OAP/OIVIT) 

empty PDU 





8 


7 


6 


5 1 4 


1 3 1 


2 


1 


Octet 3 




Future use 


Octet .. 


Future use 


Octet 7 



A.6.3 RLC-HANDOVER-NOTIFY encoding (OAP/OIVIT) 





8 


7 1 


6 1 5 1 4 


3 


2 


1 


Octet 3 




Network 


Time-valid 


Octet 4 


Traffic 


Quality 


Future use 


AP-ID 


Octet 5 






AP-ID 


1 NET-ID 


Octet 6 


NET-ID 


Octet 7 


MAC-ID 



A.6.4 RLC-HANDOVER-REQUEST encoding (OAP/OMT) 





8 1 7 


1 6 1 


5 1 4 


1 3 


2 1 1 


Octet 3 




AP-ID-OLD 


Octet 4 


AP-ID-OLD 


Octet 5 


MAC-ID-OLD 


Octet 6 


NET-ID-OLD 


Octet 7 


NET-ID-OLD 


1 DUC-EST 1 




Future use 





A.6.5 RLC-HANDOVER-REQUEST-NACK encoding (OAP/OMT) 

Empty PDU 





8 


7 


6 


5 1 4 


1 3 1 


2 


1 


Octet 3 




Future use 


Octet .. 


Future use 


Octet 7 
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A.6.6 RLC-HO-INFO-DISTRIBUTION-ACK encoding (OAP/OMT) 





8 


7 


6 


5 1 4 


3 


2 1 1 


Octet 3 




Future use 


Octet 4 


Future use 


Octet 5 


Octet 6 


Octet 7 


MAC-ID 



A.6.7 RLC-FORCE-HANDOVER encoding (OAP/OiVIT) 





8 1 7 1 6 


5 


4 


3 1 2 1 1 


Octet 3 




Return 


Future 


Cause:TrafLoad/Badlink/Operator 


Octet 4 


FREOUENCY-INDEX 


Octet 5 


AP-ID 


Octet 6 


AP-ID 1 


Future use 


1 NET-ID 


Octet 7 


NET-ID 



A.6.8 RLC-FORCE-HANDOVER-ACK encoding (OAP/OIVIT) 





8 


7 


6 


5 1 4 


3 


2 1 1 


Octet 3 




Future use 


Octet 4 


Future use 


Octet 5 


Octet 6 


Octet 7 


MAC-ID 



A.6.9 RLC-AP-ABSENCE encoding (OAP) 





8 


7 


6 


5 


4 


3 1 2 1 


1 


Octet 3 




Future use 


FIRST-MAC-FRAME 


Octet 4 


LAST-MAC-FRAME 


Octet 5 


Octet 6 


Future use 


Octet 7 



A.6.10 RLC-DFS-MT-INIT-REPORT-REQUEST encoding 
(OAP/OMT) 





8 1 7 1 6 1 5 1 4 1 3 


2 1 1 


Octet 3 




MEASUREMENT-TYPE 


Octet 4 


FREOUENCY-INDEX 


Octet 5 


Future use 


ADJ-CH-INT 


Octet 6 


Future use 


Octet 7 


MAC-ID 



A.6.1 1 RLC-DFS-MT-INIT-REPORT-REQUEST-ACK encoding 
(OAP/OMT) 





8 


7 


6 


5 1 4 1 3 


2 


1 


Octet 3 




Future use 


REP-INI 


Octet 4 


Future use 


Octet ... 


Octet 7 
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A.6.12 RLC-CHANGE-FREQUENCY encoding 





8 1 7 1 6 


5 


4 


3 1 2 1 


1 


Octet 3 




Future use 


FIRST-MAC-FRAME 


Octet 4 


LAST-MAC FRAME 


Octet 5 


Octet 6 


FREOUENCY-INDEX 


Octet 7 


Future use 



A.6.13 RLC-UPLINK-PC-CALIBRATION encoding 





8 


7 


6 


5 1 4 


3 


1 2 1 


1 


Octet 3 




Future use 


PC-OFFSET 


Octet .. 


Future use 


Octet 7 



A.6.14 RLC-IVIT-ALIVE-REQUEST encoding 





8 


7 


6 


5 1 4 1 3 1 


2 


1 


Octet 3 




Future use 


Octet 4 


MT-ALIVE-INTERVAL 


Octet 5 


Octet 6 


Octet 7 


Future use 



A.6.15 RLC-IVIT-ALIVE-REQUEST-ACK encoding 





8 


7 


6 


5 1 4 


3 


2 1 1 


Octet 3 




Future use 


Octet 4 


Future use 


Octet 5 


Octet 6 


Octet 7 


MAC-ID 



A.6.16 RLC-IVIT-ALIVE encoding 





8 


7 


6 


5 1 4 


3 


2 1 1 


Octet 3 




Future use 


Octet 4 


Future use 


Octet 5 


Octet 6 


Octet 7 


MAC-ID 



A.6.17 RLC-IVIT-ALIVE-ACK encoding 

Empty PDU 





8 


7 


6 


5 1 4 


1 3 1 


2 


1 


Octet 3 




Future use 


Octet .. 


Future use 


Octet 7 
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A.6.18 RLC-MT-ABSENCE encoding (OAP/OMT) 





8 1 7 


6 


5 1 4 1 3 


2 1 1 


Octet 3 




Future use 


Octet 4 


Future use 




MT-ABSENCE-TIME 




Octet 5 


Future use 


Octet 6 


Octet 7 


MAC-ID 



A.6.19 RLC-MT-ABSENCE-ACK encoding (OAP/OIVIT) 



empty PDU 







8 1 7 1 6 


5 1 4 


1 3 1 2 


1 






Octet 3 




Future use 






Octet .. 


Future use 






Octet 7 




A.6.2( 


3 RLC-SLEEP encoding (OIVIT) 












8 1 7 1 6 1 5 1 4 


1 3 


2 


1 






Octet 3 




Future use 


care-of-bc 






Octet 4 


Future use 


SLEEP-GROUP 








Octet 5 


Future use 






Octet 6 






Octet 7 


MAC-ID 




A.6.2 


1 RLC-SLEEP-ACK encoding (OIVIT) 












8 1 7 1 6 


5 1 4 


1 3 1 2 


1 






Octet 3 




Futu 


e use 


care-of-bc 






Octet 4 


Future use 


SLEEP-GROUP 








Octet 5 


OFFSET 






Octet 6 






Octet 7 


Future use 















A.7 Transfer Syntax Tables for SCH DUCC messages 
A.7.1 RLC-DM-MODIFY-COMPLETE-ACK encoding (OAP/OMT) 





8 


7 


6 


5 1 4 


3 


2 1 1 


Octet 3 




Future use 


Octet 4 


MAC-ID 


Octet 5 


Future use 


Octet 6 


Octet 7 


MAC-ID 
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A.7.2 RLC-DM-CONNECT-COMPLETE-ACK encoding 
(OAP/OMT) 





8 


7 


6 


5 1 4 


3 


2 1 1 


Octet 3 




Future use 


Octet 4 


MAC-ID 


Octet 5 


Future use 


Octet 6 


Octet 7 


MAC-ID 



A.8 Transfer Syntax Tables for other RLC SCH 
messages 



A.8.1 RLC-NO-SUPPORT encoding 





8 1 7 1 6 1 5 1 4 1 


3 


2 


1 


Octet 3 




Future 


SCH-LCH 


Octet 4 


Not-supported-PDU-type 


Octet 5 


Future use 


EXTENSION-TYPE 


Octet 6 


Future use 


Octet 7 


MAC-ID (if Uplink) 
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Annex B (normative): 
Types 

The implementations shall follow the numbering (0,1,...) in the enumerated lists. 
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Table B.I : Data description 



ADJACENT-CH-INTERFERENCE ::= ENUMERATED { 
channel-inteference-0 (0) } 


field size 2 bits 


AGE-OF-MEASUREMENT 
::= INTEGER(0..4095) 


In request: The maximum age for the last BCH 
measurement. If the BCH on the requested frequency 
has been measured within this time for other reasons, 
e.g. handover, the MT is not required to perform the BCH 
decoding. Instead, the MT may use stored values of the 
BCH content and the RSS measured on the BCH . 
In report: Indicates the time since the measurement was 
performed. This is important if the AP polls the MT for 
measurement results. Age is the number of MAC frames 
since the measurement was finished. Age=0 means that 
the measurement was performed in the previous MAC 
frame. 

The accuracy +/- 2 MAC frames is allowed for the value. 
The backoff value due to collisions in the RACH shall not 
be taken into account. 


ALLOCATION-TYPE ::= ENUMERATED { 
basic (0), 
fca (1), 
fsa (2) 1 


3 bits 

Fixed Capacity Agreement 
Fixed Slot Allocation 


AP-ID 

::= INTEGER (0 .. 1023) 


Access Point Identifier [5]. 
AP-ID value for future use. 


APT-ADDRESS-LENGTH 
::= INTEGER (0.. 10) 


4 bits field 

Indicates the number of bits assigned for transceiver 
identification starting from the least significant bit of the 
AP ID. In case of single transceiver Aps the apt-address- 
length shall be set to zero. 

Values of apt-address-length greater than zero shall be 
indicated only, when the AP supports radio handover. In 
a single coverage area using Aps with identical net-id the 
apt-address-length shall be set to the same value in all 
Aps. 


AP-TOKEN-AUTH-ENCR::= SEQUENCE { 
token TOKEN, 
authentication-encryption-list AUTHENTICATION- 
ENCRYPTION-LIST, 

auth-encr-selected AUTH-ENCR-INFO } 




AP-TOKEN-AUTH-ENCR::= SEQUENCE { 
token TOKEN, 
authentication-encryption-list AUTHENTICATION- 
ENCRYPTION-LIST, 

auth-encr-selected AUTH-ENCR-INFO } 




ARQ-DATA ::= SEQUENCE { 

arq-window-size WINDOW-SIZE, 
arq-nr-of-retr INTEGER (0.. 15)} 


3 bits 


ARQ-DELAY 

::= INTEGER (0..3) 


ARQ Delay Class. [5] 


AUTH-ENCR-INFO ::= SEQUENCE { 
auth-info AUTH-INFO, 
encr-info ENCR-INFO } 




AUTHENTICATION-ENCRYPTION-LIST ::= SEQUENCE 

(SIZE(1..15))0F 

AUTH-ENCR-INFO 


The list is ordered by preference. The first item has the 
highest preference. 


AUTH-INFO ::= ENUMERATED { 
no-authentication (0), 
pre-shared-key-based (1), 
signature-based-512 (2), 
signature-based-768 (3), 
siqnature-based-1024 (4)} 


4 bits field size 


AUTH-RESPONSE ::= CHOICE {; 

pre-shared [0] OCTET STRING(SIZE(1 6)), 
rsa-signature512 [1] OCTET STRING(SIZE(64)), 


Used for authentication 
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rsa-signature768 [2] OCTET STRING (SIZE(96)), 
rsa-siqnaturel 024 [31 OCTET STRING (SIZE(1 28))} 




AUTH-RESP0NSE-PART1 ::= OCTET STRING 
(SIZE(16..32)) 


Only the values 16 and 32 are used. See CHALLENGE. 


AUTH-RESP0NSE-PART2 ::= OCTET STRING 
(SIZE(16..48)) 


Only the values 16, 32 and 48 are used. See 
CHALLENGE. 


BCH-FOUND ::= ENUMERATED { 
bch-not-found (0), 
bch-found (1)} 


field size 1 bit 


BCH-RX-LEVEL 

::= INTEGER(0..63) 


Measured signal strength of the BCH on frequency f. It is 
an index to a signal strength [4] 


BROAD-WINDOW ::= ENUMERATED { 
bw-size32 (0), 
bw-size64 (1), 
bw-size128 (2), 
bw-size256 (3)} 


2 bits. Window size for repeated broadcast PDUs, see 
[5]. 


CARE-OF-BROADCAST ::= ENUMERATED { 
dont-care-of-broadcast (0), 
care-of-broadcast (1)} 


field size 1 bit 


CC-CAPABLE ::= ENUMERATED { 
not-cc-capable-device (0), 
cc-capable-device (1)} 


field size 1 bit 


CC-HO-CAP ::= ENUMERATED { 
cc-ho-not-supported (0), 
cc-ho-supported (1)} 


field size 1 bit 


CHALLENGE ::= OCTET STRING (SIZE (16)) 


Used in the authentication procedure. 
A random number sent to the other party 
that calculates a response according to the 
authentication procedure, with the challenge as an input. 


CL-ATTRIBUTES ::= OCTET STRING (SIZE(0..44)) 


The convergence layers exchange information between 
themselves, transparent to RLC. 


CL-ATTR-PR ::= ENUMERATED ( 
cl-attr-not-present (0), 
cl-attr-present (1)} 


field size 1 bit 


CL-COMMON-ATTR ::= OCTET STRING (SIZE(0..31)) 




CL-CONN-ATTR ::= OCTET STRING (SIZE(0..31)) 




CL-DATA ::= SEQUENCE { 
cl-id CL-ID, 
cl-attributes CL-ATTRIBUTESj 




CL-ID ::= ENUMERATED { 

} 


8 bit field size. To be defined. 


CL-VERSION 

::= INTEGER(0..255) 


Both MT and AP send their own version in Link Capability 
procedure. 


CL-VID::= SEQUENCE { 
cl-id CL-ID, 
cl-version CL-VERSION} 




CL-V1D-LIST::= SEQUENCE (SIZE(0..5)) OF CL-VID 


List of convergence layers with their versions. 


cMAX-CONNINTEGER::=10 




CMAX-DESCR-LIST INTEGER ::= 16 




cMAX-ID-LIST INTEGER ::= 16 




CODER-TYPE ::= ENUMERATED { 
reed-solomon-21 6-200 (0)} 


8.2.1.1.1 Field size: 2 bits 
Reed-Solomon code 


COMMON-KEY ::= CHOICE { 
no-encr [0] NULL, 
des-encr [1] OCTET STRING(SIZE(8)), 
tripledes [2] OCTET STRING(SIZE(24))} 


A key used to encrypt multicast and/or broadcast traffic 


C-U-G ::= ENUMERATED { 
open-user-group (0), 
closed-user-group (1)} 


Open group: All MT's allowed to attempt association. 
Closed group: Only MTs with a matching network 
operator identifier allowed to attempt 
association 
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CYCLIC-PREFIX ::= ENUMERATED { 
t400ns (0), 
tSOOns (1)} 


800ns in mandatory, 400ns is optional [4]. 


DH-PUBLIC-VALUE-HALF ::= OCTET STRING (SIZE(48)) 


DH=Diffie-Hellman. Used to create encryption key. 


DIRECTION ::= ENUMERATED { 
simplex-forward (0), 
simplex-backward (1), 
duplex (2), 
duplex-symetric (3)} 


simplex connection, forward direction 

simplex connection, backward direction 

duplex connection 

duplex-symetric - the same data used for both directions 


DIRECT-MODE-CAP ::= ENUMERATED { 
no-dm-capabilities (0), 
dm-capabilities (1)} 


1 bit field size 


DISASSOCIATION-CAUSE ::= ENUMERATED { 
unknown-dis-cause (0), 
user-disassociation (1), 
operator-disassociation (2), 
low-qos-dis (3), 
trafic-overload-dis (4), 
authentication-failed (5), 
mt-powerdown (6), 
ap-powerdown (7), 
mismatched-resources (8)} 


8 bits. A "user" can be any "user" of the system, both at 
the MT and the AP. 


DIL-POWER-CONTROL ::= ENUMERATED { - 2 bits 
dil-fixed-pc (0),- Fixed power = Max power- 3dB 
dil-dynamic-pc (1) } - Dynamic dil power control 

as defined in HE 




DLC-ATTRIBUTES ::= OCTET STRING (SIZE(0..44)) 


The DLC layers exchange information between 
themselves, transparent to RLC. 


DLC-ATTR-PR ::= ENUMERATED { 
dic-attr-not-present (0), 
dic-attr-present (1)} 


field size 1 bit 


DLCC-DESCR ::= SEOUENCE { 
dicc-id DLCC-ID, 
cl-conn-attr CL-CONN-A 1 1 R} 




DLCC-DESCR-LIST ::= SEQUENCE (SIZE(1..16)) OF 
DLCC-DESCR 


The maximum number of elements is limited by the LCH- 
PDU length and the number of other parameters used in 
the same RLC PDU 


DLCC-ID 

::= INTEGER (0 .. 63) 


DLC Connection Identifier [5]. 






DLCC-ID-LIST ::= SEOUENCE 
(SIZE(1..cMAX-ID-LIST)) OF DLCC-ID 


The maximum number of elements is limited by the LCH- 
PDU length and the number of other parameters used in 
the same RLC PDU 


DLC-VERSION 

::= INTEGER (0..255) 


Both MT and AP send their own version. 


DM-ATTRIBUTES ::= SEQUENCE { 
dil-power-control DIL-POWER-CONTROL, 
rx-arq-win-size WINDOW-SIZE, 
tx-arq-win-size WINDOW-SIZE} 


A minimun ARO window size shall be negotiated here. 
The DM-attribute is used by home extension to negociate 
some specific DM parameters. 


DM-USE-COMMON-KEY ::= ENUMERATED { 
no-common-key (0), 
use-common-key (1)} 


1 bit 


DUC-DESCR ::= SEOUENCE { 

direction [0] DIRECTION, 
dIcc-id [1] DLCC-ID, 
cl-conn-attr [2] CL-CONN-ATTR, 
forward-descr [3] DUC-DIRECTION-DESCR-FW 

OPTIONAL, 

backward-descr [4] DUC-DIRECTION-DESCR-BW 

OPTIONAL} 


forward-descr shaW be used, when direction indicates 
simplexjorward, duplex or duplex_symmetric. 
bacl<ward-descr shaW used, when direction indicates 
simplex_bacl<ward, duplex. 


DUC-DESCR-LIST ::= SEQUENCE 
(SIZE(1..cMAX-DESCR-LIST)) OF DUC-DESCR 


The maximum number of elements is limited by the LCH- 
PDU length and the number of other parameters used in 
the same RLC PDU. 


DUC-DIRECTION-DESCR ::= SEOUENCE { 
allocation-type [0] ALLOCATION-TYPE, 
cyclic-prefix [1] CYCLIC-PREFIX, 
ec-mode [2] EC-MODE, 


fee shall be present, whien fee-used is set. arq-data shall 
be present, when ec-mode is set to acknowledged-mode. 
fca-c/esc/- shall be present, when allocation-type indicates 
fca. 
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fee-used 

arq-data 

fee 

fca-descr 


[3] FEC-USED, 

[] ARQ-DATA OPTIONAL, 
[5] FEC-DESCR OPTIONAL, 
[6] FCA-DESCR OPTIONAL } 
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DUC-DIRECTION-DESCR-BW 
::= DUC-DIRECTION-DESCR 


DUC description to be used for the backward direction. 


DUC-DIRECTION-DESCR-FW 
::= DUC-DIRECTION-DESCR 


DUC description to be used for the fonward direction. 


DUC-ESTABLISHED ::= ENUMERATED { 
no-duc-established (0), 
dues-established (1)} 


field size 1 bit 

Indicates, if the MT maintains on-going unicast DUCs. 

This parameter shall be considered by the target AP 

during network handover when re-establishing on-going 

DUCs. 


DUC-EXT-IND ::= ENUMERATED { 
no-duc-ext (0), 
duc-ext (1)} 


field size 1 bit 


DUTY-CYCLE ::= ENUMERATED { 

fiveper (0) 
tenper (1) , 
twentyper (2) , 
thirtyper (3) , 
fortyper (5) 
sixtyper (6) , 
eightyper (7) , 
hundredper (8) } 


Percent of the MAC frame that the MT can use for uplink 

transmission. Upper limit, which AP may take into 

account. 

5% 

10% 

20% 

30% 

40% 

60% 

80% 

100% 


EC-MODE ::= ENUMERATED { 
arq-not-used (0), 
arq-used (1), 
repetition-mode (2)} 


field size 2 bits 


ENCR-INFO ::= ENUMERATED { 
no-encryption (0), 
des (1), 
tripleDES (2)} 


4 bits field size 


ENCRYPTION-ALGORITHM-PROPOSAL ::= SEQUENCE 
(SIZE(1..15)) OF ENCR-INFO 


The list is ordered by preference. The first item has the 
highest preference. 


ERROR-CORR-MODE ::= ENUMERATED { 
repetition-mode (0), 
unacknowledqed-mode (1)} 


1 bit field size, used in CL-BROADCAST-JOIN-ACK 
message 


EXTENSION-TYPE ::=ENUMERATED { 
basic-ric (0), 
home-extension (1), 
business-extension (2) } 


3 bits field size. This field is set to every RLC PDU. The 
usage of the field allows re-usage of the RLC PDU TYPE 
field for different extensions. This field shall be encoded 
to to indicate the PDUs defined in the present 
document. 


FCA-DESCR ::= SEQUENCE { 

nb-of-sch INTEGER (0..1), 
sch-per-nb-frames INTEGER (1 ..15), 
phy-mode-sch PHY-MODE-PROPOSED, 
phy-mode-lch PHY-MODE-PROPOSED, 
Ich-per-nb-frames INTEGER (1 ..15), 
nb-of-lch INTEGER (0..255), 
min-nb-of-lch INTEGER (0..255)} 


Nb=number 


FCA-USED ::= ENUMERATED { 
fca-not-used (0), 
fca-used (1 ) } 




FEC-DESCR ::= SEQUENCE { 

coder-type CODER-TYPE, 
interleaver-type INTERLEAVER-TYPE} 




FEC-USED ::= ENUMERATED { 
fec-not-used (0), 
fee-used (1)} 


field size 1 bit 


FIRST-MAC-FRAME 
::=INTEGER(0..15) 


RLC_CHANGE_FREQUENCY: Index to the first frame 
transmitted on new frequency 
RLC_AP_ABSENCE: The first frame where AP will 
transmit again after AP absence. 
The reference for the number is the MAC frame where 
the AP stops transmitting. denotes the MAC frame 
immediately after the MAC frame where the AP stops 
transmitting. 
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FORCE-HANDOVER-CAUSE ::= ENUMERATED { 
unspec-fho-cause (0), 
traffic-overload (1), 
bad-link (2), 
operator-action (3), 
cell-closure (4), 
mt-behaviour (5), 
qos-not-achived (6)} 


3 bits field size 


FRAME-COUNTER 
::= INTEGER (0.. 15) 


4-bit Frame counter 


FRAME-NUM 

::= INTEGER (0..65535) 


Integer value with unit FRAMES (16 Bit) 


FREOUENCY-BAND ::= ENUMERATED { 
lower-band-only (0), 
upper-band-only (1), 
lower-and-upper-band (2)} 


Field size 2 bits. A node declares which frequency band 
that it can use. Low band: 5180-5320 MHz. High band: 
5500-5700 MHz. 


FREQUENCY-INDEX ::= INTEGER (1..255) 


Field size 8 bits. The value points to the nominal carrier, 
see [4]. 


GROUP-MAC-ID 

::= MAC-ID (224..255) 


MAC ID used for a multicast group. The value 255 shall 
be used for overflow multicast traffic, that is, when the 
values 224-254 are used up. 


HANDOVER-CAUSE ::= ENUMERATED { 
unspec-ho-cause (0), 
interference (1), 
link-quality (2), 
better-link (3), 
not-enough-resourcess (4)} 


field size 4 bits 

Defines the reason why an MT performs a handover. 


IDENTIFIER-FORMAT ::= ENUMERATED { 
network-id-available (0), 
network-id-unavailable (1)} 


3 bits field size 

Two values are used at present. One value for network 
operator available and the other value for no network 
operator available. 


IDENTIFYER::= CHOICE! 
empty NULL, 
full OP-ID} 




INCLUDE-MT-ID ::= ENUMERATED { 
donot-include-mtid (0), 
include-mtid (1) } 


field size 1 bit 


INFO-COUNT ::= INTEGER (0..7) 




INFO-TYPE ::= ENUMERATED { 
new-info (0), 
retrans-info (1)} 


field size 1 bit 


INTERLEAVER-TYPE ::= ENUMERATED { 
no-interleaver (0), 
three-branch-conv (1)} 


field size 2 bits 


KEEP-CONNECTIONS ::= ENUMERATED ( 
donot-keep-conn (0), 
keep-connections (1)} 


field size 1 bit 


KEY-ID 

::= INTEGER (0..255) 


Identifier for a common encryption key. A key can be 
used in different places and to save resources a short 
identifier is used instead of the key itself. 


LAST-MAC-FRAME 

::= INTEGER{0.. 65535) 


16-bit field size. 

RLC_CHANGE_FREQUENCY: Index to the last 
transmitted frame on old frequency 
RLC_AP_ABSENCE: The last frame that the MT 
transmits at before AP Absence. 
Reference is the MAC frame in which the message from 
AP is received by the MT. The value shall mean the 
first MAC frame after the one in which the message was 
received by the MT. 


LAST-OWN-BCH-RX-LEVEL 
::= BCH-RX-LEVEL 


Measurement result: RSS on the used frequency BCH 


LENGTH-OF-EACH-CL-ATTR 
::=INTEGER(0..15) 




MAC-ID 

::= INTEGER (0 .. 255) 


8 bit Identifier used in communication between MT and 
AP/CC or another MT [5]. 
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MAC-IDO ::= MAC-ID(O) 


A subtype of MAC-ID. A fixed value used for upstream 
communication before an MT has got a MAC-ID of its 
own (RLC MAC ID ASSIGN and 
RLC RBCH ASSOCIATION REQUEST). 


MAC-ID-AND-CL-DATA ::= SEOUENCE { 
mac-id-choice MAC-ID-CHOICE, 
cl-data CL-DATA } 




MAC-ID-AND-CL-DATA-LIST ::= SEQUENCE (SIZE(1 ..7)) 
OF MAC-ID-AND-CL-DATA 




MAC-ID-CHOICE ::= CHOICE { 

group-mac-id [0] GROUP-MAC-ID, 
unicast-mac-id [1] MAC-ID, 
broadcast-mac-id [2] MAC-ID} 




MAC-IDS ::= SEQUENCE 
(SIZE(1..7)) OF MAC-ID-CHOICE 




MAGIC 

::= INTEGER (0..63535) 


Random number, 16 bits. The same magic number shall 
be kept during the retransmissions of the messages that 
use it. It is used as a temporary identifier until MT has got 
its own MAC-ID. 


MAXIMUM-AGE-OF-BCH-MEASUREMENT 
::= AGE-OF-MEASUREMENT 


Sort: Number of MAC frames. 


MD5-0N-KEY ::= OCTET STRING (SIZE(16)) 


The MD5 algorithm operating on key 


MD5-0N-N0NCE ::= OCTET STRING (SIZE(16)) 


The MD5 algorithm operating on nonce 


- 




MEASUREMENT-TYPE ::= ENUMERATED { 
type-a (0), 
type-b(1), 
type-c (2), 
type-u (3)} 


field size 2 bits 

The measurement types a,b,c are described in 
MEASUREMENT_REQUEST_MESSAGEs. 
Measurement type u (undefined) means that the MT has 
performed a measurement on the specified frequency, 
which does not follow any of the predefined 
measurement types. In this case, it is up to the AP to 
request necessary measurements from the MT. The 
adjacent channel flag indicates if the measurement 
concerns adjacent channel interference or not. 


MEASUREMENT-WINDOW 
::= INTEGER (0..63) 


6 bit field size. 

On other frequency measurement window defines how 
many MAC-frames time units shall be spent on 
measurements. If the measurement type is percentiles 
this time is spent on RSS statistics measurements. If 
measurement type is short the measurement window is 5 
frames and the RSS from the strongest BCH obtained is 
reported together with the BCH-content. If the type is 
complete 5 frames of the window is used for BCH-synch 
and decode and the rest spent on RSS statitics 
measurements. 

On used frequency measurement-window gives a coarse 
description of the measurement interval and the final 
description is given by the AP-absence message or the 
FCH- empty-part of frame information. 


MORE-AUTH ::= ENUMERATED { 
more-auth-pdu (1), 
last-auth-pdu (0)} 


field size 1 bit . Indicates whether more PDUs are to 
follow or not. Used when authentication information is 
longer than what can be contained in one PDU. 


MORE-JOINS ::= ENUMERATED { 
no-more-joins (0), 
more-joins (1)} 


field size 1 bit 


MT-ABSENCE-TIME 
::= INTEGER (0..63) 


Defines the absense period of the MT in MAC frames. 


MT-ALIVE-INTERVAL 

::= INTEGER (0.. 167721 5) 


Period (in number of frames) that MT Alive procedure is 
commanded to be triggered in. 


MT-AUTH-CONTENT ::= CHOICE {; 

ieee [0] OCTET STRING (SIZE(6)), 
ext-ieee [1] OCTET STRING (SIZE(8)), 
net-acc-id [2] OCTET STRING (SIZE(1 ..46)), 
dist-name [3] OCTET STRING (SIZE(1 ..46)) 
compressed [4] OCTET STRING (SIZE(1 6)), 
generic [51 OCTET STRING (SIZE(1 ..92))} 


Type of MT authentication identifier, 
ieee [8], 
ext-ieee [9], 
net-acc-id [10], 
dist-name [11] 

The compressed type can be used if the available 
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} 


authentication key identifier is so long that it is not 
possible to carry in the defined RLC messages. The 
compressed authentication key identifier is calculated as 
follows: compressed-authentication-key- 
identifier=MD5(available_authentication_key_identifier) 

The generic type is a non-structured octet string 


MT-AUTH-ID-TYPE ::= ENUMERATED { 

ieee (0), 

ext-ieee (1), 

net-acc-id (2), 

dist-name (3) 

compressed (4), 

generic (5) } 
} 


Type of MT authentication identifier, 
ieee [8], 
ext-ieee [9], 
net-acc-id [10], 
dist-name [11] 

The compressed type can be used if the available 
authentication key identifier is so long that it is not 
possible to carry in the defined RLC messages. The 
compressed authentication key identifier is calculated as 
follows: compressed-authentication-key- 
identifier=MD5(available_authentication_key_identifier) 

The generic type is a non-structured octet string 


MT-TOKEN-AUTH-ENCR ::= OCTET STRING (SIZE(1 6)) 


The MD5 algorithm operating on token 


NET-ID 

::= INTEGER (0 .. 1023) 


10 bit Identifier for network on DLC- level [5]. Value is 
for future use. Certain other numbers are reserved for the 
standardized use by public network operators. 


NETW-OP-ID-GLOBAL ::= lASString (SIZE(0..31)) 


ASCII string of up to 32 characters, that is up to 32 
octets. This part is globally unique. 


NETW-OP-ID-LOCAL ::= 
IA5String(SIZE(0..31)) 


ASCII string of up to 32 bytes, that is 32 
characters/digits. The length is 32 minus "global". 


NETWORK-OPERATOR-ID ::= SEOUENCE { 
identifier-format IDENTIFIER-FORMAT, 
identifyer IDENTIFYERj 




NONCE ::= OCTET STRING (SIZE(16)) 


A random value used during authentication 


NUMBER-OF-SAMPLES 
::=INTEGER(0.. 16383) 


14 bitfield size. 

In percentile and complete report: The measurement 
length, given in number of 8 us samples taken in RSS 
statistics measurements. 


OMNI-ANTENNA-USED ::= ENUMERATED { 
omni-antenna-not-used (0), 
omni-antenna-used (1)} 


1 bit field size. 

Omni antenna definition: If the maximum antenna gain, 
measured in the horizontal plane, is 6 dB greater than 
the average antenna gain in the horizontal plane, the 
antenna is considered as a directional antenna. 
Otherwise the antenna is considered as non-directional. 
Note: the calculation of the average gain should be 
performed in linear scale, not dB scale. 


OP-ID ::= SEOUENCE { 

unique-length UNIOUE-LENGTH, 
c-u-g C-U-G, 
netw-op-id-local NETW-OP-ID-LOCAL, 
netw-op-id-qlobal NETW-OP-ID-GLOBAL } 




PC-OFFSET ::= ENUMERATED { 
future-useO (0), 
plusSdb (1), 
plus3db (2), 
minus3db (3), 
minus6db (4), 
reset-tx-level (7)} 


3 bit field size. See [4] 


PDU-TYPE-CHOICE ::= CHOICE ( 
Ich RLC-LCH-PDU-TYPE, 
sch RLC-LCH-PDU-TYPE } 




PHY-GUARD-INTERVAL ::= ENUMERATED { 
normal (0), 
short (1)} 


normal OFDM symbol guard interval 
short OFDM symbol guard interval 
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PHY-MODE ::= ENUMERATED { 
cBPSKI-2 (1), 
CBPSK3-4 (2), 
cQPSKI-2 (3), 
cQPSKI-3 (4), 
C16QAM9-16 (5), 
C16QAM3-4 (6), 
C64QAM3-4 (7)} 


4 bits field size 
BPSK, code rate 1/2 
BPSK, code rate 3/4 
OPSK, code rate 1/2 
OPSK, code rate 3/4 
160AM, code rate 9/16 
160AM, code rate 3/4 
640AM, code rate 3/4 


PHY-MODE-PROPOSED ::= ENUMERATED { 
nopliy-mode-proposal (0), 
cpBPSK1-2 (1), 
cpBPSK3-4 (2), 
cpOPSK1-2 (3), 
cpOPSK1-3 (4), 
cp16QAM9-16 (5), 
cp16QAM3-4 (6), 
cp64QAM3-4 (7)} 


4 bits field size 
no proposal 
BPSK, code rate 1/2 
BPSK, code rate 3/4 
OPSK, code rate 1/2 
OPSK, code rate 3/4 
160AM, code rate 9/16 
160AM, code rate 3/4 
640AM, code rate 3/4 


REJECT-CAUSE ::= ENUMERATED { 
try Again (0), 
overLoaded (1), 
auth-incompatibilty (2), 
encr-incompatibility (3), 
unknown (4), 
dic-incompatibility (5)} 


field size 4 bits 

Indicates the reason, why a specific request is rejected. 


RELEASE-CAUSE ::= ENUMERATED { 
unknown-release-cause (0), 
normal-release (1), 
low-qos (2), 
timed-out (3), 
lack-of-resources (4), 
network-operator-release (5)} 


field size 4 bits 


REPORTING-INITIALIZED ::= ENUMERATED { 
reporting-not-initialized (0), 
reportinq-initialized (1)} 


field size 1 bit 


REOUEST-INITIALIZATION ::= ENUMERATED { 
request-not-initialized (0), 
request-initialized (1)} 


field size 1 bit 


RESET-FILTERS ::= ENUMERATED { 
no-filter-reset (0), 
reset-filters (1)} 


field size 1 bit 

Flag to indicate if the MT shall reset the filters for PDU 

error rate averaging. 


RETURN-FLAG ::= ENUMERATED { 
return-not-allowed (0), 
return-allowed (1)} 


field size 1 bit 


RLC-VERSION 

::= INTEGER (0..255) 


Both MT and AP send their own version in Link Capability 
procedure. The present document is RLC version 1 . 


RSS-INDEX ::= ENUMERATED { 
rss-minimum (0), 
rss-5-percent (1), 
rss-1 0-percent (2), 
rss-20-percent (3), 
rss-30-percent (4), 
rss-40-percent (5), 
rss-50-percent (6), 
rss-60-percent (7), 
rss-70-percent (8), 
rss-80-percent (9), 
rss-90-percent (10), 
rss-95-percent (11), 
rss-maximum (12)} 


field size 4 bits. 

Percentage of the maximum value. 


RSS-INDEX ::= INTEGER(0..15) 




RSS-INDEX-LIST ::= SEQUENCE (SIZE(1..5)) OF RSS- 
INDEX 




RSS-STATISTICS 
::= INTEGER(0..63) 


Measurement result: RSS statistics on frequency f. 
Number of samples in the different percentiles, minimum 
or maximum. 
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RSS-STATISTICS ::= ENUMERATED { 
] 


Number of samples in the different percentiles, minimum 
or maximum. 

??Check the details - There is an integer with the same 
name (mistake?) 


RSS-STATISTICS ::= INTEGER(0..63) 




RSS-STATISTICS-LIST ::= SEQUENCE (SIZE(0..4)) OF 
RSS-STATISTICS 




RSS-VALUE 

::= INTEGER(0..63) 


6 bits. When used in the Link Capability messages, it is 
the latest Received-Signal-Strength value measured by 
the MT before the signal was sent. When used in the 
RLC LINK CAPABILITY ACK or 
RLC_HANDOVER_LINK_CAPABILITY_ACK message, it 
is the same value that was sent in the 
RLC_LINK_CAPABILITY message. It is an index to an 
RSS value given in dBm, see [4]. 


SCH-LCH ::= ENUMERATED { 
sch (0), 
Ich (1)} 


1 bit field size 


SECTOR-ID 

::= INTEGER (0..7) 


3 bits field size. 


SEED ::= BIT STRING (SIZE(52)) 




SEND-NW-TOKEN ::= ENUMERATED { 
don't-send-nw-token (0), 
send-nw-token (1)} 


1 bit field size 


SLEEP-GROUP 

::= INTEGER (0.. 15) 


Sleeptime = 2'^SLEEP-GROUP (4 Bit). The value 
means, that no sleeping is allowed. 


START-AUTHENTICATION ::= ENUMERATED { 
dont-start-auth (0), 
start-auth (1)} 


1 bit field size 


START-DUC-SET-UP ::= ENUMERATED { 
donot-start-setup (0), 
start-setup (1)} 


1 bit field size 


START-ENCRYPTION ::= ENUMERATED { 
dont-start-encr (0), 
start-encr (1)} 


1 bit field size 


START-INFO-TRANSFER ::= ENUMERATED { 
dont-start-info-transfer (0), 
start-info-transfer (1)} 


1 bit field size 


START-OF-MEASUREMENT 
::=INTEGER(2..15) 


The start of the measurement interval is given in number 

of MAC frames. The starting point for counting the start- 

of-measurement shall be counted from the frame the 

start-of-measurement parameter was received (number 

0). 

The usage of the parameter is described in the DFS 

chapters. 


SUPPORTED64QAM ::= ENUMERATED { 
suppot64QAM (1), 
no-support64QAM (0) } 


field size 1 bit 


SUPPORTED-FCA ::= ENUMERATED { 
support-fca (1), 
no-support-fca (0)} 


field size 1 bit 


SUPPORTED-FSA ::= ENUMERATED { 
support-fsa (1), 
no-support-fsa (0)} 


field size 1 bit 


TIME-GAP-ACH-UPLINK 
::= INTEGER (0..7) 


The minimum time, in ^s, between the end of the ACH 
and the first uplink transmission of each individual MT [5]. 
= 0, 1 = 16, 2 = 32, 3 = 64, 4 = 128, 5 =256, 6 = 512, 
7 = 1024 


TOKEN ::= OCTET STRING {SIZE(1 6)) 


Used for network handover authentication 


TRAFFIC-LOAD ::= ENUMERATED { 
notusedO (0), 
notused? (7)} 


3 bits, not used in phase 1 
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TX-LEVEL ::= ENUMERATED { 
dbm30 (0), 
dbm27 (1), 
dbm24 (2), 
dbm21 (3), 
dbm18 (4), 
dbm15 (5), 
dbm12 (6), 
dbm9 (7), 
dbm6 (8), 
dbm3 (9), 
dbmO (10), 
dbmmS (11), 
dbmm6 (12), 
dbmm9 (13), 
dbmm12 (14), 
dbmm15 (15)} 


4 bits. The AP transmit level that the MT has read from 
the field in the BCH of the measured AP. 


UNIQUE-LENGTH 
::=INTEGER(0..31) 


The unique length field indicates the length of the 
globally unique part of the network operator identifier in 
bytes. 


USE-OMNI-ANTENNA ::= ENUMERATED { 
dont-use-omni-antenna (0), 
use-omni-antenna (1)} 


1 bit field size 


WINDOW-SIZE ::= ENUMERATED { 
arq-not-used (0), 
w-size32 (1), 
w-size64 (2), 
w-size128 (3), 
w-size256 (4), 
w-size512 (5)} 


3 bits. See [5] 
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Annex C (normative): 
RLC TIMERS 

T_short =16 frames=32 ms 

T_medium = 8*T_short=128 frames=256 ms 

T_long = 8*T_medium=1024 frames=2048 ms 

T_dfs = start-of-measurement + measurement-window + 5 frames 

Table C.I : MT Timers 



MT (testing AP) 


Value 






T rbch association req 


T short 


T mac id assign 


T short 


T linl< capability 


T short 


T l<ey excliange mt 


T short 


T autlientication 


T medium 


T autlientication ap 


T long 


T autlientication-ap 


T medium 


T dm common l<ey distr acl< 


T short 


T info 


T short 


T groupjoin 


T short 


T group leave 


T short 


T cl broadcast Join 


T short 


T cl broadcast leave 


T short 


T disassociation mt 


T short 


T connect ack 


T short 


T setup mt 


T short 


T connect mt 


T short 


T release mt 


T short 


T modify req mt 


T medium 


T modify mt 


T medium 


T reset mt 


T short 


T dfs mt init report 


T short 


T sector handover req 


T short 


T handover request 


T short 


T handover notify 


256 frames 


T nw signalling handover 


T medium 


T force handover return 


256 frames 


T sleep request 


T short 


T mt alive 


T short 


T dm setup mt 


T short 


T dm connect mt 


T short 


T dm connect cmpt mt 


T medium 


T relay setup mt 


T medium 


T dm release mt 


T medium 


T relay release mt 


T medium 


T dm modify req mt 


T short 


T dm modify mt 


T short 


T dm modify cmpt mt 


T medium 


T relay modify mt 


T medium 


T dm reset mt 


T medium 
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Table C.2:AP Timers 



AP (testing IMT) 


Value 






T mac id assign acl< 


T short 


T linl< capability acl< 


T short 


T l<ey excliange ap 


T long 


T autlientication mt 


T long 


T autlientication acl< 


T long 


T dm common l<ey distr 


T short 


T nw signalling handover ack 


T short 


T info ack 


T short 


T disassociation ap 


T short 


T unicast key refresh 


T medium 


T common key refresh 


T medium 


T connect ap 


T short 


T setup ap 


T short 


T release ap 


T short 


T modify ap 


T medium 


T modify req ap 


T medium 


T reset ap 


T short 


T force handover 


T short 


T force handover return 


256 frames 


T handover association 


T short 


T handover link capability ack 


T short 


T handover notify 


256 frames 


T nw signalling handover ack 


T short 


T nw handover complete 


T short 


T ho info distribution 


T short 


T mt alive request 


T short 


T mt absence 


T short 


T dm setup ap 


T short 


T dm connect ap 


T short 


T dm connect cmpt ap 


T short 


T dm release ap 


T short 


T dm modify req ap 


T short 


T dm modify ap 


T short 


T dm modify cmpt ap 


T short 


T dm reset ap 


T short 



£75/ 



184 ETSI TS 101 761-2 VI .1.1 (2000-04) 



Annex D (normative): 

SDL specification of the RLC protocol 

This specification has been produced using Specification and Description Language - SDL and Abstract Syntax 
Notation No 1 - ASN.L 

The archive containing all available formats of the specification is ts_10176102v010101p0.zip. 



D.1 The SDL Graphical form (SDL/GR) 

The graphical form of SDL specification is available in tool specific format. All relevant files are contained in the 
archive rlcsdl_v02r00.zip included in the archive ts_10176102v010101p0.zip. The achive also contains the ASN.l files 
that are part of the model. 



D.2 The SDL Textual format (SDL/PR) 

The SDL textual format is tool independent. It preseves the meaning of the specification but does not preserve the 
graphical layout. SDL/PR is available in the archive rlcsdl_v02r00_pr.zip included in the archive 
ts_10176102v010101p0.zip. 



D.3 The SDL Common Interchage format (SDL/CIF) 

The SDL Common Interchange format is tool independent. It preseves the meaning of the specification and the 
graphical layout. SDL/CIF is available in the file archive rlcsdl_v02r00_cif zip included in the archive 
ts_10176102v010101p0.zip. 



D.4 The ASN.1 files 



The ASN.l files that are specifying the abstract message structure are included with the SDL/GR but are also available 
in the archive rlcsdl_v02r00_asn.zip included in the archive ts_10176102v010101p0.zip. 



D.5 The PDF format 



The SDL specification including the ASN. 1 part is available for viewing/printing in PDF format in the file 
rlcsdl_v02r00.pdfints_10176102v010101p0.zip. 
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